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Section 1. Introduction to This Course 



COURSE OVERVIEW 



3 



This course is intended to give Series/1 personnel a general knowledge 
of the concepts and theory incorporated in the Event Driven Executive 
systenn Version 3. Upon completion of this course, the student should 
be able to install, generate and maintain an Event Driven Executive 
system as well as write and execute basic application programs. 

The prerequisite for this course is successful completion of Introduction 
to Smaller Systems Student Text (SR30-0185) or equivalent experience. 
Programming experience using high level languages is also strongly 
recommended. 



The Event Driven Executive instruction set and system support 
programs have been divided into several broad functional groups, 
each group constituting a section of this study guide. An attempt 
has been made to organize the sections in a logical sequence for 
study. Each section, however, is also as modular as possible, and 
can be studied as a separate unit, or in a sequence other than 
presented, if desired. 

Sect/on 1. Introduction to This Course 

Contains introductory material, as well as a brief operational 

overview of the Event Driven Executive system. 

Section 2. Instruction Format 

Coding conventions/syntax rules for coding Event Driven 

Executive instructions. 

Section 3. Programs/Tasks 

This section covers program/task structure, application program 
design considerations, and all of the Event Driven Executive 
instructions used for task control and synchronization. 

Section 4. Data Definition 

Section 5. Data Manipulation 

These two sections cover all of the basic instructions required to 

define, move, or perform logical or arithmetic operations on data 

in storage. 

Section 6. Queue Processing 

Discussion and illustration of the queue definition and processing 

instructions. 

Section 7. Program Control 

How to define and use both Event Driven Executive subroutines, 

and subroutines written in Series/1 Assembler Language. 
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Section 8. Program Sequencing 

Discussion and illustration of IF and DO structures, and the 

relational statements used with them. 

Section 9. Timers 

Instructions to access the system's 24 hour clock and the elapsed 

time clock, and to wait for a time delay are discussed. 

Section 10. Dis/</Diskette I/O 

Discussion and examples of defining and accessing data sets from 

an application program. 

Section 1 1. Terminal I/O 

Section 12. Data Formatting 

The comprehensive terminal I/O support provided by the Event 

Driven Executive is discussed in detail, with several coding 

examples. Data Formatting support is used with terminals, and 

therefore immediately follows. 

Section 13. Sensor Input /Output 

This section includes some basic sensor I/O concepts, as well as 
how to incorporate the sensor I/O support in a supervisor and to 
access sensor I/O devices from a user program. 

Section 14. System Utilities 

All of the system utilities are described. Those utilities required 

most often are discussed in detail. 

Section 15. System Installation 

This section covers installation of the supplied supervisor and system 
programs as received from PID, and generation of a tailored supervisor, 
using the online Program Preparation Facility. 

Section 16. Program Preparation Using $EDXASM 
$FSEDIT (text editor), $EDXASM (Event Driven language assembler), 
$LINK (link editor), $UPDATE (object module formatter), and 
$JOBUTIL (job stream processor) are used to prepare a program for 
execution. Included are examples of the use of the COPY CODE 
assembler feature and the AUTOCALL link editor option. 

Section 17. Program Preparation Using $S1ASM 

This optional topic is for those users who will be assembling Series/1 

assembler language and/or Event Driven language programs using 

$S1 ASM, the Series/1 Macro Assembler (Licensed Program 5719-ASA). 

Section 18. Session Manager 

Organization and operation of the Session Manager programmer pro- 
ductivity tool. 
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MATERIAL REQUIREMENTS 

Course Materials Form No. 

*IBM Serles/1 Event Driven Executive 
Licensed Program Study Guide SR30-0436 

Additional Materials 

*IBM Series/1 Event Driven Executive 
System Guide SC34-1702 

*IBM Series/1 Event Driven Executive Operator's 
Reference, Messages and Codes SC34-1703 

*IBM Series/1 Event Driven Language 
Reference SC34-1706 

**IBM Series/1 Macro Assembler Language 

Reference SC34-0317 

***IBM Series/1 Event Driven Executive 
Communications and Terminal 
Application Guide SC34-1705 

***IBM Series/1 Event Driven Executive 

Internal Design LY34-0202 

* Required to complete this course. 

**Not required to complete course, but may be a useful 
reference for users who will be preparing programs 
written in Series/1 assembler language, using the 
Series/1 Macro Assembler (57 19- ASA) (optional topic 
in Study Guide). 

***Not required to complete this course. These manuals address 
topics that are not covered in the study guide, but which may 
be of interest to some students. 



STUDY TIPS 



Each section has a set of objectives. Read the objectives carefully so 
that you understand what you should be learning in that section. 
For each topic you will find a READING ASSIGNMENT. Read the 
reading assignment and then continue in the Self Study Guide. At the 
end of most sections you will find a Review Exercise. Try to complete 
it prior to looking at the correct answers and be sure you understand 
your mistakes before proceeding to the next topic or section. 

The total amount of study time you will need is estimated at 50 to 
60 hours. This may extend over a period of two or three weeks if 
your study periods are brief and somewhat separated because of 
other duties. 
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For best results, set a short time goal rather than a long one and then 
make every effort to meet that goal. Study sessions should be about 
2 hours long but use whatever time you wish. You may find that 
several short sessions are more productive than one longer session. 



COURSE OBJECTIVES 



The student upon completion of this self-study course should be able 
to: 

1 . Describe the major components and facilities of the Series/1 
Event Driven Executive system 

2. Install an Event Driven Executive system on a Series/1 

3. Use the utility programs to maintain a system 

4. Invoke Supervisor utility functions from a terminal 

5. Use most of the Event Driven Executive instructions 
necessary to code application programs 

6. Load application programs from a terminal, or from other 
programs 

7. Understand the use of overlay programs, multitasking, and 
task/program synchronization 

EVENT DRIVEN EXECUTIVE COMPONENTS-VERSION 3 r~^^ 



The Event Driven Executive software offering consists of five 
licensed programs: 

1. Basic Supervisor and Emulator {5719-XS3) 

2. Event Driven Executive Utilities (5719-UT5) 

3. Event Driven Executive Macro Library/Host (5740-LM4) 

4. Event Driven Executive Program (5719-XX4) 
Preparation Facility 

5. Event Driven Executive Macro {5719-LM7) 
Library 



Basic Supervisor and Emulator {5719-XS3) 



V... 



Event Driven Executive application programs are made up of instructions 
coded in the Event Driven Language. At execution time, the assembled 
output of these instructions is passed to the emulator portion of the 
Supervisor/Emulator, and the Emulator links to the system routines 
required to perform the functions. The Supervisor portion of the 
Supervisor/Emulator manages system and I/O resources for application 
programs in execution. 
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Event Driven Executive Utilities (5719-UT5) 



The system utilities also operate under the control of the supervisor. 
They provide online, interactive support for a tailored supervisor 
generation, source module preparation, disk initialization, data set/ 
volume maintenance, etc. 



Event Driven Executive Macro Library/Host (5740-LIVI4) 



This is a set of libraries and procedures to be installed on a host 
System/370, so that Event Driven Executive or Series/1 assembler 
programs can be assembled on the host machine. The macros support 
all of the Event Driven Executive functions supported by the Event 
Driven Executive Program Preparation Facility (5719-XX4). 

Prerequisites for host program preparation include: 

o A binary synchronous communications line between the Series/1 
and the host 

• Use of either the S/370 Event Driven Executive Host Communi- 
cations Facility lUP (5796-PGH) or the RJE utility supplied 
with Event Driven Executive Utilities (5719-UT5), for transfer of 
data sets between the two systems 

© On the host, installation of the S/370 Program Preparation 
Facilities for Series/1 FDP (5798-NNQ) 



Event Driven Executive Program Preparation Facility (5719-XX4) 



The Event Driven Executive Program Preparation Facility consists 
of programs which allow the user to assemble and link edit appli- 
cation programs concurrently with the execution of other pro- 
grams (including other program preparation programs). The user 
can also reconfigure, assemble, and link edit custom supervisors 
online. 

The Event Driven Executive assembler, $EDXASM, (part of 5719-XX4) 
is used to assemble application programs written in the Event Driven 
language. As long as no Series/1 assembler language code is included 
in application source code (USER exit routines), this is the only 
assembler required for program preparation. 

Licensed program 5719-ASA, (separately orderable program, not part of 
5719-XX4) the Series/1 Macro Assembler, also runs under the Event 
Driven Executive system, and is used to assemble programs written in 
Series/1 assembler language. When installed under the Event Driven 
Executive, the Series/1 Macro Assembler is called $S1 ASM. If the 
Series/1 Macro Library (5719-LM7) is also installed, $S1ASM may be 
used to assemble Event Driven Executive supervisors and programs 
written in the Event Driven Language, as well as programs written in 
Series/1 assembler language. 
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Event Driven Executive Macro Library (5719-LI\/I7) 



This library contains the macro prototypes for the Event Driven 
instruction set, and al! the macros necessary to build a supervisor 
tailored to a particular system configuration. This library is used when 
preparing programs using the Series/1 Macro Assembler $S1 ASM (not 
required if system generation/program preparation is done with 
$EDXASM). 



EVENT DRIVEN EXECUTIVE - AN OPERATIONAL OVERVIEW 



The Event Driven Executive component that controls execution 
of user-written applications is the Supervisor/Emulator. It is a multi- 
programming supervisor, capable of controlling concurrent program 
execution. 

The basic unit of work for the supervisor is an instruction. Instructions 
are combined to form tasks, each of which has an assigned priority, 
used by the supervisor to allocate system resources. 

An application program may have more than one task (multitasking). 
Each task competes for system resources with every other task in the 
system, based on task priority. Each task runs independently of all 
other tasks. 

Programs/tasks are made up of Event Driven Executive instructions 
that have been processed by an assembler and prepared for execution 
by the link/formatting system utilities. At execution time, the 
Supervisor/Emulator analyzes an instruction's assembled format, and 
links to the appropriate supervisor routine to perform the operation. 
Following the completion of each instruction, the supervisor processes 
the next sequential instruction in the highest priority task that is 
ready. 

The Supervisor/Emulator occupies the lowest 10 to 40+ K bytes 
of Series/1 storage, depending on what support is included. The rest 
of storage is available for user application programs. Programs may be 
loaded by a terminal operator request, or by execution of a LOAD 
instruction in a currently executing program. Programs are loaded 
dynamically, using a relocating loader, into the smallest available 
area of storage of sufficient size to contain them. 

Other functions/services performed by the supervisor include task 
dispatching (starting/ending tasks), I/O interrupt handling, program/ 
task synchronization, and provision for inter-program communication 
via a global common area. 
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Section 2. Instruction Format 



EVENT DRIVEN EXECUTIVE BASIC INSTRUCTION FORMAT 



OBJECTIVES: After completing this topic, the student should be 
able to describe the basic format used in coding Event Driven 
Executive Instructions. 



LANGUAGE SYNTAX/CODING CONVENTIONS 



The Event Driven Executive instruction set was originally imple- 
mented as a macro library, using a macro assembler on the native or 
a host machine to process application source modules. $EDXASM 
is an online Event Driven Executive language assembler, not a macro 
assembler, and does not utilize a macro library to process application 
source modules. Although macros are not used, macro assembler 
language syntax and coding conventions are still followed, thereby 
retaining compatibility with previous releases. 

If required, Series/1 macro assembler language syntax/coding con- 
ventions may be reviewed in the Series/1 Macro Assembler Language 
Reference (SC34-0317). 
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INSTRUCTION FORMAT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "General Instruction Format." 

The basic Event Driven Executive instruction format is: 

label op opndl ,opnd2, opndn,KEYW0RD=,Pl=,P2=, . . .Pn= 

where 

1 abel identifies the location of a particular instruction and 

can be referenced by other instructions. 

op is the operation to be performed by the Series/1 (MOVE, 
ADD, etc.) 

opndl ,opnd2, ... .opndn are positional operands. The 

meaning of each parameter or operand is defined by its 
position in the operand field of the instruction. The number 
of positional operands varies with each Instruction type. 

opndl is normally the "to" or target location. 

opnd2 is normally the "from" or source loaction. 

KEYWORD= are keyword operands. The keyword (PREC, RESULT, 
EVENT, etc.) specifies a particular parameter to be 
used in that instruction's execution. 

P 1= , etc are keyword operands that allow positional operand 

modification at execution time. 



._> 



2-2 SR30-0436 



Figure 2-1 shows the relationship of the various parts of a source 
statement to the general instruction format. (The ADD instruction 
is discussed in detail in "Section 5. Data Manipulation", and 
is used here only to illustrate the basic instruction format.) In this 
example, three positional operands are used. FIELD is the name of the 
"to" or "target" location, DATA is the "from" or "source" location, 
and the third positional operand is the integer value "1", the "count" 
operand. A keyword operand, PREC= is also coded; in this case, the 
"S" Indicates "single precision." 



ADDIT ADD FIE 

/ \ I 



LABEL 



FIELD, DATA, 1,PREC=S 




OP 


opndl 


\ opnd3 


KEYWORD 


(operation 


(to or 


\ (count) 


OPERAND 


to be 


target 


\ 


(specifying single 


performed 


location) 


opnd2 


precision) 


by 




(from or 




computer) 




source location) 





Figure 2-1. Source statement/general instruction format relationship 

For the ADD instruction, the count and PREC = operands are not 
required; they have values to which they will default if not coded 
(the values coded in the illustration are, in fact, the default values 
for these operands). In the ADD, the "count" operand applies to the 
first positional operand only (the number of consecutive values, 
beginning at location FIELD, to which the value in DATA is to be 
added), and the "PREC =" operand, as coded, applies only to the 
first positional operand and the result (which is also the first 
operand, in this example). 

Other instructions may not have a count or PREC= operand or, if 
they do, they may apply to other than the first positional operand. 
The general syntax of an Event Driven Executive instruction adheres 
to the basic format just discussed; the meaning of the operands, 
and the number of operands allowed differs depending on the 
instruction type. 
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INSTRUCTION FORMAT REVIEW EXERCISE - QUESTIONS 

f ) 1. In the study guide, and in the reading assignment, the terms 

—^ "operand" and "parameter" are both used. These terms 

are interchangeable, and both refer to labels/names/values 
in the operand field of an instruction. 



^ 



True 
False 



2. In the operand field of an instruction, all positional operands 
used must precede (from left to right) any keyword operands 
used. 

True 

False 



3. All instructions have the same number of positional operands, 
but the number of keyword operands varies from instruction 
to instruction. 

True 

False 



4. In the operand field of an instruction, positional operands are 
separated by commas, but keyword operands may be separated 
by blanks or by commas. 

True 

False 



5. The meaning of a positional operand, in a given instruction, 
is determined by its position (first, second, etc.), while the 
meaning of a keyword operand is determined by the keyword 
used. 

True 

False 



6. Labels beginning with "$" have a special meaning to the system, 
and are reserved for system use. 

True 

False 



Instruction Format 2-5 



INSTRUCTION FORMAT REVIEW EXERCISE - ANSWERS 



1. True. Both terms are used interchangeably, throughout the 
study guide and the manuals. For example, 

parameter one 
parameter 1 
first parameter 
parm1 

operand one 
operand 1 
first operand 
opnd1 

are all used at one time or other to refer to the first positional 
operand in an operand field being discussed. 

A possible area of confusion might be an instance when "parameter" 
is used to describe information passed to another program or a 
subroutine, rather than to reference an element of an operand 
field. Normal attention to the context in which the term is used 
will usually prevent any misunderstanding. 

2. True. All positional operands must be coded before (to the left 
of) the first keyword operand. After all positional operands have 
been coded, multiple keyword operands may be coded in any 
sequence desired; all keywords are analyzed in light of the meaning 
of the keyword itself, rather than its position within the operand 
field. 

3. False. Different instructions vary in the number of required 
positional operands (must be coded, no default), optional 
positional operands (will default to predetermined value if 
not coded), and required/optional keyword operands. 

4. False. All operands, keyword or positional, are separated 

by commas, with no imbedded blanks allowed. When the first 
blank is detected, all further information is considered a comment. 

In the situation where two or more optional positional operands 
are allowed, and you skip one and code the other, the skipped 
(defaulted) operand must be indicated by a comma if the coded 
operand follows it in position. 
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Example: 

label op opndlvapnd2,opnd3^Q^nd4 

REQUIRED OPTIONAL 

VALID OPERAND STRUCTURES 

opndl,opnd2 

REQUIRED OPERANDS ONLY - OPTIONAL OPERANDS 
(opnd3, opnd4) TAKE DEFAULT 

opndl,opnd2,opnd3 

REQUIRED OPERANDS PLUS FIRST OPTIONAL OPERAND 
(opndS) CODED - opnd4 TAKES DEFAULT VALUE 

opndl,opnd2,opnd3,opnd4 

REQUIRED AND OPTIONAL OPERANDS CODED 

opndl,opnd2, ,opnd4 

REQUIRED AND LAST OPTIONAL OPERAND {opnd4) 
CODED, SKIPPED OPERAND (opndS) INDICATED BY A 
COMMA 

INVALID OPERAND STRUCTURES 

opndl,opnd2,opnd4 

THE VALUE YOU THOUGHT YOU CODED FOR opnd4 
WILL BE ASSIGNED TO opnd3, AND opnd4 WILL TAKE 
THE DEFAULT 

5. True. Self explanatory. 

6. True. There is no system enforced discipline preventing a user 
from defining storage locations with labels beginning with the "$" 
character. However, because system defined functions/locations/ 
resources have labels beginning with this character that may be 
referenced by operands in user-written instructions, confusion can 
be avoided if users restrict their own definitions to labels not 
beginning with "$". 
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Section 3. Program/Tasks 



OBJECTIVES: Upon successful completion of this topic, the student 
should be able to: 

1. Describe programs and tasks as used in an Event Driven Executive 
System 

2. Define an application program structure that fits system and 
application requirements 

3. Use the Event Driven Executive program and task definition 
statements 

4. Understand and use the task synchronization statements 

5. Include operator attention routines in a program 

PROGRAM/TASK CONCEPTS AND STRUCTURE 

READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
System Guide (SC34-1702) "Program/Task Concepts and Structure" 
^-^ through "Multiple Program Structure." IBM Series/1 Event Driven 

f ^ Executive Language Reference (SC34- 1706), "Task Control." 

System resources in an Event Driven Executive system are allocated 
to tasks according to the priorities of the tasks. A task is a unit of work, 
defined by the application programmer. A program is a disk- or 
diskette-resident collection of one or more tasks, that can be loaded into 
storage for execution. Although "program" and "task" are sometimes 
used synonymously, the basic executable unit for the supervisor is 
the task. 

Task priority is assigned by the application programmer when the task 
Is coded. Valid priorities range between and 51 1, with being the 
highest possible priority, and 51 1 the lowest. Tasks with priorities 
between and 255 execute on hardware level 2, and those between 
256 and 51 1 on level 3. 
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Single Task Program 



For most applications, an elaborate program structure is not 
required, and programs will consist of a single task, as shown in 
Figure 3-1. 



PROGA 



PROGRAM AS SINGLE TASK 

• NO EXECUTION OVERLAP WITHIN PROGRAM 

• PROGRAM COMPETES FOR SYSTEM RESOURCES 
WITH OTHER TASKS CURRENTLY IN SYSTEM 



Figure 3-1. Single task program structure 

Figure 3-2 is an example of the type of application that lends itself 
to the single task program structure. The job is sequential in nature, 
and will be waiting for operator input most of the time. There is no 
requirement for asynchronous execution of multiple functions or 
I/O overlap with processing, and nothing to be gained by a more 
complex structure. 



OPERATOR REQUEST LOADS 
"CUSTOMER FILE UPDATE" 
PROGRAM 




UPDATE 



INAL 



1. GET CUSTOMER NAME FROM TERI 
(OPERATOR INPUT) 

2. SEARCH CUSTOMER FILE FOR NAME 

3. READ CUSTOMER RECORD 

4. DISPLAY CUSTOMER RECORD ON TERMINAL 

5. ACCEPT UPDATE FROM TERMINAL (OPERATOR 
INPUT) 

6. WRITE UPDATED RECORD TO CUSTOMER FILE 

7. GO BACK TO STEP 1 IF MORE RECORDS TO 
UPDATE 

8. ELSE, END UPDATE PROGRAM 



Figure 3-2. Single task application example 
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Multiple Task Programs 



Figure 3-3 illustrates a multitasking program structure. PROGA is 
started up by the system when the program is loaded, and is called the 
PRIMARY TASK. The other tasks shown will not start up until a user- 
coded command is executed that tells them to begin. PRIMARY 
TASKS go into execution as a result of the program's being loaded into 
storage, while initiation of SECONDARY TASKS is a user responsibility. 
Once in execution, all tasks within a program compete for system re- 
sources with one another, and with all other tasks active in the system. 
The supervisor considers each task as a discrete unit of work, and 
assigns resources based on task priority, regardless of which tasks are 
PRIMARY orSECONDARY. 



PROGA 



TASKX 



TASKY 



TASKZ 



PROGRAM MADE UP OF MULTIPLE TASKS 

• CONCURRENT (ASYNCHRONOUS) EXECUTION 

OF TASKS WITHIN PROGRAM 
o TASKS COMPETE FOR SYSTEM RESOURCES 

WITH ALL OTHER TASKS CURRENTLY IN SYSTEM 



Figure 3-3. Multitasking program structure 



Figure 3-4 is an example of an application that makes use of multi- 
tasking. The program repetitively reads a group of Analog Input 
points, performs calculations on the data and stores the results in an 
output area on disk. 



Program/Tasks 3-3 




OPERATOR REQUEST 
LOADS "A/I DATA 
REDUCTION" PROGRAM 




AIRDUCE 

1. START "AISCAN" TASK 

2. WAIT FOR "AISCAN" TASK TO COMPLETE 

3. READ A/I VALUES FROM DISK INTO WORK AREA 
'4. START "AISCAN" TASK 

5. PERFORM DATA REDUCTION ON DATA IN WORK 
AREA 

6. WRITE RESULTS TO OUTPUT AREA ON DISK 

7. GO BACK TO STEP 2 

AISCAN 

1. READ A/I POINTS INTO STORAGE 

2. WRITE A/I VALUES TO DISK 

3. TASK "AISCAN" COMPLETED 



Figure 3-4. Multitasking application example 

To take advantage of multitasking, the reading of the Analog Input 
points has been defined as a separate task, which also buffers the collec- 
ted data to disk. When the program is loaded into storage, the supervisor 
starts up the primary task, AIRDUCE. The first step in AIRDUCE is 
to start up the secondary task AISCAN. AIRDUCE then waits for 
completion of the reading and buffering of the first set of Analog 
Input values. 

When AISCAN completes, AIRDUCE starts up again, and retrieves 
the buffered data from disk. AISCAN is restarted and, while the 
first set of values is being processed, the second set is being col- 
lected; the two functions are overlapping. 
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Multiple Program Structure 



As already mentioned, an application program consists of a user- 
written collection of one or more tasks that has been prepared 
for execution and stored under a unique name on disk/diskette. 
A terminal operator can request that a program be loaded into 
storage and placed in execution by entering a request for the super- 
visor load utility $L and supplying the program name. 

Programs may also be loaded by executing a LOAD instruction in 
another program that is already in execution (use of the LOAD 
statement is discussed later in this section). When the supervisor 
receives a request to load a program, either from a terminal or a task 
already in execution, it finds the program on disk/diskette, finds a 
section of unused storage large enough to accommodate the program, 
loads the program from disk/diskette, relocates it Into the storage 
area, and starts up the program's Initial task. When a program com- 
pletes execution, the supervisor releases the storage it occupied so 
that the area can be used to load other programs. 

Because programs are dynamically relocated into storage as load 
requests are received, the size and structure of the programs can have 
an effect on system throughput. To illustrate this, assume there is 
a payroll application consisting of the following functions: 



"N 



Function 

SORT 



PART-TIME 
WAGES 

FULL-TIME 
WAGES 

SALARIED 
WAGES 

WRITE 
CHECKS 



Description 

Separate part-time hourly, full-time hourly, 
and salaried employee data into three 
separate files. 

Process all records in part-time employee 
file 

Process all records In full-time employee 
file 

Process all records in salaried employee file 



Print checks for all employees 



r^ 



Program/Tasks 3-5 



Although the payroll job just described is a fairly straightforward 
application, which could be coded as a single program, there may 
be valid reasons for breaking it up into multiple programs. One con- 
sideration is the size of a program, in relation to the storage available 
on the system and the number and size of other programs that may 
need to run concurrently. If the size of PAYROLL in relation to the 
total storage available for user programs is as depicted in Figure 3-5, 
you can see that, once PAYROLL is loaded, little storage will be left 
for loading other programs. 

SERIES/1 
STORAGE 



SUPERVISOR 



(AVAILABLE 
STORAGE) 



PAYROLL 



Figure 3-5. Program structure 



Conversly, if other programs are already in execution when the load 
of PAYROLL is requested, there may be some delay before enough 
contiguous storage to accommodate so large a program becomes 
available and the load can again be attempted. 

Below is a redefinition of the payroll application with each function 
coded as a separate program. 



Program Name 

SORTIME 



PARTIME 
FULLTIME 
SALTIME 
CHECKS 



Description 

Separate part-time hourly, full-time hourly, 
and salaried employee data into three 
separate files 

Process all records in part-time employee file 

Process all records in full-time employee file 

Process all records in salaried employee file 

Print checks for all employees 
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As can be seen in Figure 3-6, each of the programs is now much 
smaller than the entire PAYROLL program. As each program 
completes execution, it would request the load of the succeeding 
program. The probability of there being enough storage to load 
other applications is greatly increased, and the chance of having to wait 
for storage to become available so that you can again attempt to load 
a program there was previously no room for, is reduced. 



r 



Overlay Program Structure 



SERIES/1 
STORAGE 



SUPERVISOR 



(AVAILABLE 
STORAGE) 



SORTIME 



PARTIME 



FULLTIME 



SALTIME 



CHECKS 



Figure 3-6. Program structure 

If system activity were very high (several other applications in 
concurrent execution), a lack of contiguous storage availability 
could still cause some difficulty in the loading of the next se- 
quential program. In a payroll application, this is acceptable, 
because it is not "time-critical"; a delay in execution of a succeeding 
step will not invalidate the final result. 



Some applications are time constrained; for example, those involving 
the processing of data acquired In realtime, where a delay in execution 
might result in data being lost or overwritten. This type of application 
must have a reasonable expectation of being loaded quickly when 
requested and, once loaded, of running to completion with minimal 
delay. 
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Coding a time-critical application as a single program ensures rapid 
execution, once it is loaded, but, if the program is large, the same 
problems exist as in the single-program payroll application (possible 
delay in load due to large amount of storage required; tying up system 
once loaded). Breaking up the program into separate programs takes 
care of the problem of size, but the requirement for nearly continuous 
execution once in operation, is still not met. Again, the level of activity 
within the system could result in a delay in loading the next in a se- 
quence of programs, a condition that cannot be tolerated in this type 
of application. 

Using the OVERLAY PROGRAM technique, both the requirement 
for a reasonable sized program and minimum execution delay can 
be met. In Figure 3-7, the application is split into separate programs. 

PHASE1 

APPLICATION 

PROGRAM 



PHASE1 



PHASE2 



PHASE3 



PHASE4 



Figure 3-7, Program overlays 

PHASE 1 is the initial program, and will load PHASE2, PHASE3, 
and PHASE4, as required. PHASE2, PHASES, and PHASE4 are 
defined as OVERLAY PROGRAMS. WhenPHASEI is loaded, the 
loader recognizes that overlay programs are referenced. The loader 
looks at each program that is designated as an overlay, and then 
reserves enough storage to hold PHASE 1 plus the largest overlay 
program. 



3-8 SR30-0436 



SERIES/1 
STORAGE 



SPACE FOR 
PHASE1 PLUS 
OVERLAY AREA 
RESERVED 
WHEN PHASEl 
IS LOADED 



SUPERVISOR 



PHASEl 



(OVERLAY 
AREA) 



(AVAILABLE 
STORAGE) 



OVERLAY AREA LARGE 
ENOUGH FOR 'PHASES' 
THE LARGEST OVERLAY 
PROGRAM 



Figure 3-8. Program overlays 

When PHASEl is loaded and in execution, and requests that 
PHASE2 be loaded, the system immediately loads PHASE2 into the 
overlay area already reserved and starts it into execution. There is no 
contention for the storage in the overlay area with other applications 
waiting to be loaded, because the overlay area is reserved for the 
exclusive use of PHASEl overlay programs. 

As each overlay program completes, PHASEl loads the next, until 
all required programs have run. When PHASE 1 terminates execu- 
tion, the storage reserved for both PHASEl and the overlay area 
is released. 

To summarize, application program structure (single program/multiple 
programs/overlays) and task structure within programs (single task/ 
multitasking) is determined by 

1 . type of application (time/non-time critical) 

2. size of application 

3. system storage size 

4. operating environment (system activity/loading) 

In general, a user should choose the simplest structure that will 
support the application's requirements. 
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PROGRAM/TASK DEFINITION 



READING ASSIGNMENT: IBM Serles/1 Event Driven Executive 
Language Reference (SC34-1706), "PROGRAM", "ENDPROG", 
"END", "TASK", "ENDTASK." 

Every Event Driven Executive application program nnust have a 
PROG RAM statement as the first statement in the program. The 
PROGRAM statement defines the basic operating environment of the 
program, including any data sets that the program will be using, the 
names of overlay programs to be loaded, the priority of the program, 
etc. 



LOCATION OF FIRST EXECUTABLE EXECUTION 

INSTRUCTION IN PRIMARY TASK PRIORITY 



\ / 



INITASK PROGRAM BEGIN, 200, DS=MASTER,PGMS=0VLAY1 



\ 



NAME OF 
PRIMARY 
TASK 



NAME OF A NAME OF AN 

DISK DATA SET OVERLAY 

PROGRAM 




ENDPROG 
END 



LAST TWO STATEMENTS 
IN EVERY PROGRAM 

Figure 3-9. Program definition 



The label of the PROGRAM statement is the name of the primary task 
(the only task, if multitasking is not used). The Event Driven Executive 
system generates a control block for the primary task (and for every 
other task defined), and assigns the first word of that control block to 
the symbolic task name. As I/O and other operations are performed 
during execution of the task, return codes and status indicators are 
placed in this word, and may be examined by instructions referencing 
the symbolic task name. 
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All Event Driven Executive programs must end with an ENDPROG 
statement, followed by an END. These two statements must be the 
last two statements in the program. 

Tasks within programs (other than the primary task) are defined by the 
TASK statement, and must end with the ENDTASK statement. The 
TASK statement performs the same functions for a task that the 
PROGRAM statement did for a program except that the data files 
and overlay programs defined in the PROGRAM statement apply for 
all tasks defined in that program, and are not specified in the TASK 
statement. 



INITASK 



PROGRAM 



BEGIN, 200, DS=MASTER,PGMS=0VLAY1 



TASK2 TASK 



START 




NO PRIORITY SPECIFIED 
DEFAULT = PRIORITY 150 



NAME OF 
SECONDARY TASK 



, ENDTASK 
ENDPROG 
END 

LAST EXECUTABLE STATEMENT 
IN EVERY SECONDARY TASK 

Figure 3-10. Task definition 



LABEL OF FIRST 

EXECUTABLE 

INSTRUCTION 
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PROGRAM/TASK EXECUTION 



READING ASSIGNMENT: IBM Serles/1 Event Driven Executive 
Language Reference (SC34-1706) "PROGSTOP", "LOAD", "WAIT 
"ECB", "ATTACH." 



Program Loading 



Event Driven Executive programs are readied for execution at the 
time they are loaded into storage from disk or diskette (a given program 
will not immediately go into execution unless its primary task has a 
higher priority than other currently executing tasks). Programs are 
loaded by a terminal operator, using the $L operator command, 
or by execution of a LOAD statement in a task already in execution. 
In both cases, the program to be loaded is referenced by the name 
under which it is stored on disk/diskette, and is either entered by 
a terminal operator, or specified as a LOAD statement operand. 
Note: The name of a program on disk has no relationship to the 
name of that program's primary task. Illustrations in this study 
guide frequently show both names the same, but this is not a 
requirement of the system. 



PROGA PROGRAM STARTA 




PROGRAMS 
LOADED BY $L 
SUPERVISOR 
UTILITY FUNCTION 



Figure 3-1 1 . Program loading from terminal 



As shown in Figure 3-1 1, copies of the same program may be in storage 
and active at the same time. The single copy of a program on disk/ 
diskette may be loaded as a separate program from one or more 
terminals (as shown) as a separate program from one or more programs 
already executing, or as an overlay by a currently executing program 
or programs. 
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Figure 3-12 is a simple example of one program loading another. The 
program consists of the single task INITASK, which will start execution 
at location BEGIN. No priority is coded on the PROGRAM statement, 
so this program will run at the default priority of 150. 



INITASK PROGRAM BEGIN 



BEGIN LOAD PTHREE 



END PROGSTOP 

ENDPROG 
END 

Figure 3-12. LOAD statement 



User disk/diskette I/O will not be performed in this program (DS= 
not coded In PROGRAM statement), and no overlay programs will 
be loaded by this program (PGMS= not coded). 

Execution of the LOAD statement at location BEGIN requests that 
a program named PTHREE be loaded into storage and readied for 
execution. The loading program will wait for the completion of the 
attempt to load PTHREE before continuing execution. 

The last statement to be executed in the loading program is the 
PROGSTOP at location END. The PROGSTOP statement must be 
the last executable statement in all programs. When PROGSTOP 
is executed, the supervisor is notified that this program's primary task 
is to be detached (made not active), various system resources that 
were assigned to this program can now be made available to other 
tasks, and the storage occupied by this program can be released for 
the loading of other programs. 

In the oversimplified example shown in Figure 3-12, the loading task 
does not check to make sure the load operation was successful. In 
actual practice, the user would want to know if the operation failed, 
and if it did, the reason for the failure. 
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In Figure 3-13, the program location ABORT is specified in the 
ERROR= keyword operand. If the load is successful, execution con- 
tinues with the statement following the LOAD. If the load operation 
fails, control is transferred to the location specified by the ERROR= 
keyword operand. In this example, ABORT is the label on a 
PROGSTOP statement and failure of the load operation would 
result in termination of the loading task. (In actual application pro- 
grams, error routines are likely to be much more complex.) 

INITASK PROGRAM BEGIN 



BEGIN LOAD PTHREE ,ERROR=ABORT 



ABORT PROGSTOP 

ENDPROG 
END 

Figure 3-13. LOAD statement 



Every task has a Task Control Block (TCB) associated with it. A task's ^— ^ 

TCB is automatically generated during the program preparation process 
when a task definition statement is encountered. A TCB consists of 
those pointers, save areas, work areas, and indicators required by the 
supervisor for controlling execution of the task in storage. 

The first word of a task's TCB is used by the supervisor to pass 
information from the system to the task, regarding the outcome of 
various operations the task has initiated. Depending on what operation 
was attempted, the value set in the first word of the TCB by the super- 
visor could indicate an arithmetic exception condition, the result of 
an attempted I/O operation, or, as in Figure 3-13, a load operation 
completion code. 

When a TCB is generated, the location of the first word is assigned 
the label on the task definition statement: the "name" of the task. 
In this study guide, and in Event Driven Executive reference docu- 
mentation, this label Is referred to as the "taskname," and the first 
word of the TCB is called the "task code word." In Figure 3-13, 
the task code word would be referenced by the taskname INITASK. 
If ABORT (specified in ERROR= keyword operand of LOAD 
statement) were the label of a user-written error routine, instructions 
in that routine could get the load operation completion code by 
using INITASK to locate the task code word. Appropriate operator 
messages could then be printed out or alternative actions taken, 
based on the precise meaning of the completion code. 
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At this point, the instructions required to examine the task code word 
have not been discussed; however there will be examples illustrating 
this technique in later sections of this course. 



Program Synchronization 



Assuming the LOAD operation was successful, and PTHREE does 
go into execution, the loading program illustrated in Figure 3-13 
has no way of telling when PTHREE finishes execution. For some 
applications, there Is no need for a loading program to be notified 
of a loaded program's completion, but there are cases where syn- 
chronizing the execution of programs or tasks is required. This can 
be accomplished by defining an event, and waiting for that event to 
happen. 

The "wait on event" facility is a signalling mechanism whereby a 
task or program can be notified when a certain event has occurred, 
and can wait or suspend execution until it does occur. Events in- 
clude such things as the expiration of a time delay, completion of 
an I/O operation, or termination of a task or program. Events may 
be user defined or, for some frequently required functions, may 
be predefined by the system. 

Completion of program execution is a predefined event, invoked by 
coding the EVENT= keyword operand in the LOAD statement. In 
Figure 3-14, the event has been named D0NE3, which is also the 
label of an Event Control Block (ECB) that is used by the supervisor 
to keep track of whether the event has or has not occurred. 



INITASK 



PROGRAM 



BEGIN 



BEGIN 



LOAD 



PTHREE, EVENT=D0NE3,ERR0R=AB0RT 



WAIT 



DONE 3 



ABORT 


PROGSTOP 


D0NE3 


ECB 




ENDPROG 




END 



Figure 3-14. LOAD statement 
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Note: If preparing programs using $S1 ASiVI, the Series/1 Macro 
Assembler, coding the EVENT= keyword operand in a LOAD state- 
ment causes an ECB with the proper label to be automatically gen- 
erated. When preparing programs using the Event Driven language 
assembler $EDXASM, the ECB must be coded, as shown in Figure 
3-14. 

When. the LOAD statement is executed, the supervisor recognizes 
that an event has been defined in the EVENT= keyword operand. 
The supervisor finds the ECB named D0NE3, and sets it to indicate 
that the event has not occurred. 

After PTHREE has been loaded, both PTHREE and the loading program 
are in execution concurrently. Eventually PTHREE will complete 
execution (execute a PROGSTOP) and, at that time, the supervisor 
will set the ECB at location D0NE3 to indicate that the event has 
occurred. 

When the WAIT statement in the loading program is executed, the 
supervisor will see that the waited-on event is D0NE3. The supervisor 
checks the ECB at location D0NE3 to see if the event has occurred. 
If it has, execution continues with the next statement following the 
WAIT. If it has not, the loading program is placed in a wait state, 
and execution will not resume until PTHREE completes. When an 
event occurs, and the associated ECB is set to indicate that it has 
occurred, the supervisor also checks to see if there are any tasks in 
wait state, waiting on that event. If there are, the supervisor changes 
them to the ready state, and they resume normal execution, based on 
priority. 

For examples of how user-written events are defined and used, see 
the discussion titled "WAIT/POST" later in this section. 

One instance where waiting on a "completion of execution" event 
such as was just described must be done is when a program loads an 
overlay. It is a user responsibility to ensure that a program that loads 
an overlay program does nor execute a PROGSTOP until the overlay 
program has completed execution. 

If a program has loaded an overlay program that is now executing, 
and the loading program issues a PROGSTOP, the storage occupied 
by the loading program and the overlay area is released to the system, 
and made available for loading other programs. Although the overlay 
area contains a program still in execution, the loader believes the 
storage is available, and may, in response to a load request, load 
another program into the same area, with completely unpredictable 
results. 
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In Figure 3-15, PTHREE is defined as an overlay program in the 
PGMS= operand of the PROGRAM statement. Up to nine overlay 
programs may be defined in a PGMS= list. 



INITASK 



PROGRAM 



BEGIN, PGMS=PTHREE 



BEGIN 



LOAD 



PGM1,EVENT=D0NE3,ERR0R=AB0RT 





WAIT 


ABORT 


PROGSTOP 


D0NE3 


ECB 




ENDPROG 




END 


Figure 3-15. 


LOAD statement 



D0NE3 



The LOAD statement requests the load of PGM1. This is a positional 
keyword reference to the PGMS= list in the PROGRAM statement. If 
multiple overlay programs were defined in the PGMS= operand, and 
you wished to load the second program in the list, the LOAD state- 
ment would be coded to load PGM2; for the third program, PGM3, 
and so on up to the maximum of PGM9. 

Note that the EVENT= keyword operand in the load statement is 
coded, and that the loading program waits for completion of the 
overlay program before issuing a PROGSTOP. 

A program's primary task is started into execution (placed in a ready 
state) by the system at the time the program is loaded. Secondary 
tasks within a program are readied for execution by an ATTACH 
instruction, issued from the primary task or another secondary task 
previously attached and running. 

In Figure 3-16, a secondary task called TASK1 is defined. TASK1 
will be started up by the ATTACH in the primary task, at location 
BEGIN. OnceTASKI has been attached, TASK 1 and INITASK, the 
primary task, execute concurrently and independently. 
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INITASK PROGRAM BEGIN 



Task Synchronization 



BEGIN ATTACH TASK1,110 



WAIT TASKDONE 
PROGSTOP 



TASKl TASK START, EVENT= TASKDONE 



ENDTASK 
ENDPROG 
END 

Figure 3-16. TASK statement 

In this example, TASKl actually runs at a higher priority than the 
primary task, and would receive preference in the allocation of system 
resources. The PROGRAM statement has no priority coded, so the 
primary task runs at the default priority of 150. There is no priority 
coded in the TASK statement, so TASKl also defaults to 150, but the 
ATTACH instruction specifies priority 1 10, which overrides any 
coded or defaulted priority in the TASK statement 



it is just as undesirable for a primary task to release storage (execute 
PROGSTOP) containing an executing secondary task, as it is for a 
program to release storage containing an overlay program still in 
execution. The TASK statement therefore has an EVENT= operand 
that is used by the attaching task in the same manner as the loading 
program used the LOAD statement's EVENT= operand. 

The example in Figure 3-17 uses many of the concepts you have just 
studied. Beginning with the PROGRAM statement at location 
INITASK, the starting address of the primary task is BEGIN; the 
primary task will run at priority 100; and two overlay programs are 
defined in the PGMS= list, PTHREE and PFIVE. At the time the 
program in Figure 3-17 is loaded into storage, enough storage will be 
reserved to hold the program plus the largest of the two overly 
programs. 
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Now assume that the program has been loaded, and the system has 
attached the primary task, INITASK. Execution starts at location 
BEGIN. This statement requests the load of overlay program PFIVE, 
because PFIVE is the second program in the PGMS= list of the 
PROGRAM statement, and the LOAD statement specifies PGM2. 
If the load of this first overlay fails, the ERROR= operand of the 
LOAD statement will cause a transfer of control to location 
0UT5BAD, the label of the PROGSTOP, and execution will 
terminate. 



INITASK 



PROGRAM 



BEGIN, 100, PGMS=(PTHREE, PFIVE) 



BEGII 
L4 



LOAD 
LOAD 



PGM2 ,EVENT=D0NE5 ,ERR0R=0UT5BAD 
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Figure 3-17. Task/program synchronization 
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If PFIVE loads properly, the next statement executed would be the 
LOAD instruction at location L4. This statement requests that pro- 
gram PFOUR be loaded into whatever storage is available (not in 
overlay area). As it is coded here, any errors encountered in attempt- 
ing to load PFOUR will be ignored, and execution will continue with 
the statement following the LOAD. 

At location A1, the primary task attaches the task defined at location 
TASK1, at a priority of 150 (default taken, and no override coded in 
the ATTACH). At this point, the primary task INITASK is executing, 
the secondary task TASK1 is executing, the primary task of PFIVE, and 
any secondary tasks it attached are running in the overlay area, and if 
PFOUR loaded successfully, it is also in execution. 

Before attempting to load overlay program PTHREE (LOAD statement 
at location L3), a WAIT at location W5 is executed, waiting on the 
completion of execution event defined in the LOAD statement which 
previously loaded PFIVE (EVENT=D0NE5). If PFIVE has not 
finished, the execution of INITASK is suspended at this point. When 
PFIVE completes, or if PFIVE were already through when the WAIT 
at W5 was issued, the LOAD at location L3 is attempted. 

This is a load of PTHREE, the first (PGM1) overlay program defined 
in the PGMS= list of the PROGRAM statement. Notice that if the 
load operation fails, the ERROR= operand of the LOAD statement 
would cause a transfer of control to location 0UT3BAD, which is a 
WAIT for the completion of TASK1, rather than to 0UT5BAD, the 
PROGSTOP. If the load of PTHREE were unsuccessful, the primary 
task is assured that no program is executing in the overlay area, but 
the secondary task TASK1 could still be in operation. Any overlay 
program in execution, and all attached tasks, must run to completion, 
before PROGSTOP is executed by the primary task. 

Note: In the figures In the study guide, no user-coded ECBs are shown 
for event control blocks named in the EVENT= operands of TASK state- 
ments. When programs are prepared using the Event Driven language 
assembler $EDXASM, the system will automatically generate the 
required ECB with the TCB created by the TASK statement, and a 
user-coded ECB is not allowed (will cause assembly errors). Users pre- 
paring programs under the Series/1 macro assembler may also allow the 
system to assign the ECB, or may code an ECB of that name, and the 
system will use the explicitly coded ECB instead of assigning one. 

If disk or diskette I/O is used in a program, the data sets to be accessed 
must be defined in the PROGRAM statement's DS= operand, in much 
the same manner as overlay programs are specified using PGMS=. This 
topic will be discussed in the DISK I/O section of this study guide. 
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QUEUABLE RESOURCES 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference {SC34-1706), "ENQ", "DEQ." 

A resource is a physical or logical entity within the system. Examples 
of resources include a subroutine or data area existing within a parti- 
cular program, or perhaps a data set or I/O device known broadly 
across the system. 

A shared resource is one that may be required by multiple tasks at 
the same time. For instance, a table of constants might be referenced 
from two or more asynchronously executing tasks within a program. 
Since, by definition, the values in the table are "constant" (not being 
altered by the tasks using them), access to the table (resource) is 
unrestricted. 

Unrestricted access to some shared resources may have undesirable 
results. As an example, if a program were printing a report on a 
printer, and other programs had free access to the printer resource, 
the report could end up with printed output from the other programs 
interspersed with report lines. In this case, the printer is a shared 
resource, but is also what is called a serially reusable resource; one 
that should be used by only one task at a time. 

The ENQ/DEQ instructions provide a mechanism by which user tasks 
may gain exclusive use of a serially reusable shared resource, and retain 
control over that resource until explicitly releasing it for use by other 
tasks. 

Figure 3-18 is an example of how queuable resources are defined 
and used. The program consists of the primary task INITASK, and two 
secondary tasks, TASKA and TASKB. Assume that both TASKA and 
TASKS have a requirement for a 500-word work area. 

Instead of putting a 500-word work area In both TASKA and TASKB, 
the programmer has chosen to save some storage, and define only 
one work area. This single work area is designated as a queuable 
resource, and will be shared by TASKA and TASKB, using the ENQ 
and DEQ instructions. 

The 500-word work area is defined in the DATA statement at location 
CALCTABL (DATA statements are discussed fully in a later section). 
The Queue Control Block for this resource is defined in the QCB 
statement at location CALCQ. 

Note: If preparing programs using the Series/1 macro assembler, coding 
an ENQ statement causes the automatic generation of a QCB with the 
same label as specified in the operand of the ENQ. When preparing 
programs using the online assembler ($EDXASM), users must code the 
QCB; it is not automatically generated. 
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Figure 3-18. ENQ/DEQ/QCB 
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When the program begins execution, the primary task attaches both 
TASKA and TASKB. TASKA and TASKB have agreed to the con- 
vention that any time either of them needs to use the work area 
CALCTABL, they will enqueue that resource by issuing an ENQ 
instruction referencing the QCB called CALCQ. Assuming that 
TASKA issues the ENQ first, the supervisor checks the QCB at 
CALCQ, finds that no other task is currently enqueued, and gives 
exclusive control of the work area to TASKA. TASKA can now use 
CALCTABL without fear of TASKB altering its contents in mid- 
execution. 

While TASKA has the work area enqueued, TASKB, which is also in 
execution, attempts to gain control of the work area by issuing its own 
ENQ of CALCQ. The supervisor checks the QCB, finds that TASKA 
is already using the resource represented by CALCQ, and therefore 
places TASKB in the wait state, waiting upon availability of the 
requested resource. 

When TASKA is finished with the work area, it issues a DEQ of 
CALCQ. The supervisor checks the QCB, and finds that TASKB 
is waiting on that resource. TASKB is placed back in the ready state, 
and the QCB is changed to indicate TASKB's "ownership" of the 
resource represented by CALCQ. 

An additional operand, not shown in the example, may be coded on 
the ENQ statement. This is the keyword operand BUSY=. It would be 
coded if, when attempting to ENQ a resource and the resource was 
busy (enqueued by another task), you did not want to suspend, waiting 
for the resource to be dequeued. You may code the label of an instruc- 
tion in the BUSY= operand (BUSY=label), and control will be 
transferred to that location if the resource is already enqueued when 
your task tries to ENQ it. 

Note that ENQ/DEQ provides protection from simultaneous access 
of a serially reusable resource only if all users requiring the resource 
agree to employ it. In the example in Figure 3-18, if one of the two 
tasks were to use the CALCTABL work area without first enqueuing 
for it, neither the supervisor nor the other task has any way of 
detecting or preventing it. 
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WAIT/POST OPERATION 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706) "POST", "RESET", "WAIT." 

Figures 3-14 through 3-17 illustrated how a program or task can 
synchronize execution with a loaded program or attached task by using 
a WAIT on the ECB named in the associated LOAD or TASK statement's 
EVENT= operand. The EVENT= operand is a convenient means of 
synchronizing the execution termination sequence of loading and 
loaded programs or attaching and attached tasks, but programs and 
tasks often require synchronization at other points In their execution. 
This can be accomplished through user-defined events, and the 
WAIT/POST mechanism. 

In the example in Figure 3-19, assume that the primary task, WAITPOST, 
at some point in its execution, requires a certain set of numeric values 
in order to continue. These values are the result of the execution of 
a calculation routine in XTASK, an attached secondary task, the primary 
task must therefore make sure that the calculation routine in XTASK 
has been executed, before proceeding with its own execution. 

The primary task could wait on the EVENT= operand in the TASK 
statement XTASK (EVENT=TASKDONE), and be assured that the 
required values had been calculated. This method would work, but 
the entire secondary task would have to run to completion before 
WAITPOST could resume execution. Depending on what else 
XTASK has to do in addition to the calculation routine, there 
could be a considerable amount of time in which the required values 
were ready for use, but WAITPOST is still in a wait state. 

Defining the completion of the calculation routine in XTASK as a user 
event allows XTASK to signal the primary task as soon as the required 
values have been generated. The event is called CALCDONE, and an 
ECB of that name is coded. ECBs for user-defined events are initially 
set up to indicate "event occurred." A WAIT issued against such an 
ECB will act as though the event has happened (fall through). There- 
fore, a RESET of the ECB must be executed before a WAIT is 
issued against it. The RESET instruction at location INITGO sets the 
ECB to indicate "event has not occurred." 
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Figure 3-19. WAIT/POST 
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In the example, execution begins with the RESET command at 
location INITGO, which changes the ECB at CALCDONE from 
its initial indication of "event occurred" to "event has not occurred.' 
At location Al, the secondary task XTASK is attached. 
WAITPOST and XTASK are now in concurrent but asynchronous 
execution. When XTASK finishes calculating the values required by 
the primary task, the POST instruction at location PI is executed, 
and the ECB at location CALCDONE is set to indicate "event 
occurred." 
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ATTENTION LISTS 



At the time the POST Is issued, the supervisor checks to see if there 
are any tasks waiting on this event. If the WAIT at W1 had already 
executed, the primary task would now be in a wait state, and the super- 
visor would place WAITPOST back in a ready state. If the WAIT had 
not yet occurred, WAITPOST would continue executing until it was 
encountered. When the WAIT was issued, the supervisor would check 
CALCDONE, and, finding the event already complete, would allow 
WAITPOST to continue execution. 

The instructions following the WAIT at W1 in the primary task, and the 
instructions following the POST at PI in the secondary task can now 
continue executing concurrently; the primary task did not have to wait 
until the secondary task terminated before using the required values. 
(Notice that the proper termination sequence for an attaching and 
an attached task is still necessary, and is provided for in the example 
by the WAIT on EVENT=TASKDONE at location W2.) 

The RESET instruction is used with user-defined events. System-defined 
events, such as those declared in the EVENT= operand of LOAD or 
TASK statements, are automatically initialized by the system. The use 
of RESET with a system-defined event may result in improper or un- 
predictable operation. 

Note: When preparing programs using the Series/1 macro assembler, 
declaring an event name in the operand of a POST statement results 
in the automatic generation of an ECB of the same name. Users of the 
Event Driven language assembler $EDXASIVI must code an ECB with a 
label matching the name in the POST operand; ECB generation is not 
automatic. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference {SC34-1706), "ATTNLIST", "ENDATTN." 

The ATTNLIST capability provides a means for an operator to 
communicate with a program using a terminal. The ATTNLIST state- 
ment is used to specify operand pairs, each pair consisting of a 
1- to 8-character operator command, and a label in the user program, 
which will receive control when that operator command is entered. 

In the example in Figure 3-20, the ATTNLIST statement defines a 
single operand pair, STOP, XTHREE. (Note that ATTNLIST, like 
ECB and QCB, is not an executable statement, and must not be coded 
within an executable code sequence.) The first "name" in the operand 
pair defines an operator command to be entered from a terminal, and 
the second is the label of the instruction in the user program that will 
be executed when that command is entered. 
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END 

Figure 3-20. Attention list 

Assume the program in the example has been loaded and is in execu- 
tion. An operator can now press the ATTENTION key on the 
terminal (the terminal used to load the program), enter the command 
STOP (defined in the ATTN LIST statement), press the ENTER key, 
and the attention routine at location XTHREE will be executed. The 
attention routine in this example, and every attention routine defined, 
must end with an ENDATTN statement. 
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Attention routines usually set a program indicator that can be checked 
by the user task; execution-time decisions (end execution, restart the 
program, load another program) can then be made, based upon the 
value in the indicator. The instructions necessary to set storage 
locations (program indicators) or check them for specific values have 
not yet been discussed, and are therefore not shown in Figure 3-20. 
For further discussion and complete examples, see the topic 
"Operator Control of Program Execution" in "Section 11. Terminal 
I/O." 
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PROGRAMS/TASKS -REVIEW EXERCISE -QUESTIONS 



1 . Most applications can be programmed as a single task. What 
type of application would justify the use of the more complex 
multitasking structure illustrated In Figure 3-3? 

Answer: 



What are the advantages of loading a program as an overlay, 
rather than just loading it into available storage? 



Answer: 



3. What disadvantages are there to the overlay program structure? 
Answer: 



4. How does a program's primary task get started up? 
Answer: 



5. What statement must be executed to release the storage occupied 
by a program? 

Answer: 



Program/Tasks 3-29 



This page intentionally left blank. /"~"n 



3-30 SR30-0436 



6. Fill in the blanks in the following paragraph, using words or 
phrases from the list below. (Some items in the list may be used 
more than once, and some not at all.) 

a. ENDTASK f. PROGRAM 

b. ATTACH g. ENDPROG 

c. entry point h. PROGSTOP 

d. TASK i. END 

e. shared resource ]. primary task 

"The first statement in all programs is the statement. 

The label of this statement establishes the name of the program's 

. The last two statements in every program must be 

and The statement 

must be the last statement in a primary task to be executed. The first 

statement in a secondary task is the statement. The 

statement which defines the end of a secondary task, and which is also 
the last to execute, is " 

7. What is the purpose of ENQ/DEQ and the QCB? 

Answer: 



The proper execution termination sequence of loading/loaded 
programs and attaching/attached tasks is an automatic function 
of the Event Driven Execution supervisor. 

True 

False 



In Figure 3-20, assuming the program is in storage and executing, 
and the operator enters QUIT after pressing the Attention key 
on the terminal, which of the following would be true? 

a. The program would immediately execute the PROGSTOP 
instruction, terminating execution. 

b. The program would execute the attention routine at 
location XTHREE. 

c. The entry would not affect program execution. 

d. The program would be placed in a wait state, waiting 
for the operator to enter XTHREE. 

e. None of the above. 
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PROGRAMS/TASKS REVIEW EXERCISES - ANSWERS 



1 . A user might consider multitasl<ing where speed of execution is of 
primary importance, and the nature of the job is such that certain 
functions may be overlapped (i.e., I/O and processing). 

2. When loading an overlay program, the loading program is assured 
that space is available, because it is reserved at the time the 
loading program itself is loaded. Also, the load of an overlay 
program is faster than the load of the same program into available 
storage would be. This is because information about the overlay 
program which the loader requires in order to load it is looked up 
at the time the loading program is loaded, and not at the time the 
LOAD command is executed, as is the case when loading a non- 
overlay program. 

3. The storage occupied by a program that loads overlays is always 
equal to the size of the loading program plus the size of the largest 
overlay. If the loading program executes without requiring any 
overlays, the overlay area, although unused. Is still unavailable 

to the rest of the system. 

4. The primary task is "attached" (made ready for execution) by 
the system (actually the loader) at the time a program is loaded 
to storage. Activation of secondary tasks is a user responsibility, 
accomplished by execution of ATTACH instructions in already 
running primary or secondary tasks. 

5. Execution of PROGSTOP makes the storage now occupied by 
a program available to the system, and terminates (detaches) 
the program's primary task. 

6. The first statement in all programs is the f) PROGRAM state- 
ment. The label of this statement establishes the name of the 
program's j) primary task. The last two statements in every pro- 
gram must be g) ENDPROG and i) END. The h) PROGSTOP 
statement must be the last statement in a primary task to be 
executed. The first statement in a secondary task is the d) TASK 
statement. The statement which defines the end of a secondary 
task, and which is also the last to execute, is a) ENDTASK. 

7. ENQ and DEQ are used to protect against the concurrent use of 
a serially reusable shared resource by asynchronously executing 
tasks. 

8. FALSE. This is a user responsibility. The system provides the 
WAIT/EVENT=/ECB to accomplish it (and WAIT/POST for 
user events), but the user must code the required statements. 

9. Choice c. is correct. The ATTN LIST in Figure 3-20 defines 
the character string STOP as the operator input required to 
execute the attention routine at location XTHREE. Any other 
entry is ignored. 
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Section 4. Data Definition 



DATA STATEMENT 



OBJECTIVES: After completing this section, the student should 
be able to: 

1 . Define data constants for the following data types: 

a. EBCDIC d. Fixed Point 

b. Hexadecimal e. Floating Point 

c. Binary f. Address Constant 

2. Define symbolic data areas using the TEXT and BUFFER 
statements 

3. Define a text message using the TEXT statement 

Data definition statements are used to define arithmetic values or 
character strings (constants and messages) and to reserve areas of 
storage for use during program execution (I/O buffers, work areas) 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706) "DATA." 

The DATA statement is the Event Driven Executive equivalent of the 
Series/1 assembler language Define Constant (DC) statement. Although 
all of the examples in this study guide use DATA statements, DC state- 
ments could be coded in their place, with the same results. 

Note: This is the only instance where a Series/1 assembler language 
statement may be coded in an Event Driven Executive program without 
employing the USER statement. See "Section 7. Program Control" 
of this study guide for discussion and examples of the USER instruction. 
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The format for the DATA statement is shown in Figure 4-1, 



name of 
first data 
constant 
defined 



OPTIONAL 



REQUIRED 




label DATA 



duptypelength' value' 

duplication number of 

factor bytes reserved 

for each data 
item defined 



type of 
data being 
defined 



nominal value 
of data item(s) 



Figure 4-1. Data statement 



The DATA statement is made up of at least two ("type" and "value") 
or as many as four parts. The first three parts ("dup," "type," and 
"length") are data descriptors or modifiers. The last part, "value," 
is coded with the actual data being defined. All parts of the DATA 
statement are coded contiguously; no separators, such as blanks or 
commas, are allowed. 

dup duplication factor. This optional operand modifier is coded 

as an integer value, indicating how many repetitions of the 
data item defined by the rest of the operand should be 
generated. If not coded, dup defaults to 1 (one). 

type data type. This defines the type of data being defined, and 

must be coded in every DATA statement. Nine data types 
are supported by the system, each one represented by a 
different alpha character. The type of data desired is indi- 
cated by coding the appropriate character in the type 
portion of the operand. 

1 ength number of bytes to be used for each data item. The length 
modifier Is supported for only hexadecimal (data type X) 
and EBCDIC (data type C) data, and is optional for those. 
Every data type (including hexadecimal and EBCDIC) has 
an Implicit length associated with it. This length is the 
number of bytes required to hold the assembled output of 
the data constant defined. For example, every EBCDIC 
character Is represented by an 8-bit (one byte) binary code. 
Therefore, when EBCDIC character strings are defined in 
DATA statements, the assembled output requires one 
storage location (one byte) for each character in the string 
(upper example in Figure 4-2), The length modifier over- 
rides this implicit length of one byte per character. The 
assembled output of the character string is placed In the 
number of bytes specified in the length modifier, with 
truncation or padding of the character string if required. 



^ 
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EBCDATA 
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EBCDATA 



ASSEMBLED 
OUTPUT 
WITH IMPLICIT 
LENGTH 



CI 


C2 


C3 




EBCDATA 



DATA 



CL5'ABC 



EBCDATA 
ASSEMBLED 
OUTPUT WITH 
LENGTH MODIFIER 



CI 


C2 


C3 


40 


40 



Figure 4-2. Length modifier 



The length modifier is coded as Ln, where n = the number 
of bytes. In the lower example in Figure 4-2, a three-byte 
character string is placed in a five-byte field (length = L5), 
and the two extra bytes are padded with EBCDIC blanks 
(hex 40). 

value nominal value of constant. The last part of the DATA 

statement operand is 'value'. When the DATA statement Is 
assembled, the assembler initializes the number of data 
elements indicated (dup) of the desired type (type code) 
to the value coded In the 'value' part of the operand. 
Note that 'value' must always be coded, and for all data 
types other than address data (type code A), the value 
is enclosed in apostrophes. 

The following examples illustrate the interaction of three parts of the 
DATA statement operand. (Length, since it is used with only two data 
types, will be ignored for the remainder of this discussion.) 



DCON 



DATA 



F'O 



The example shown will define a one-word integer value. Initialized 
to zero. The optional dup Is not coded, so the length will default to 
the Implicit length of the data type, which is one word for F type data. 



Data Definition 4-3 



CCON DATA 5C'A' 

The example shows a data type of C (EBCDIC), and the duplication 
factor is 5. This statement would generate a five byte field of the 
EBCDIC representation of the character A (in hex, C1C1C1C1C1). 
The duplication factor applies to the data defined within the enclosing 
apostrophes of the value portion of the operand. If the DATA 
statement is written as follows; 

CCON DATA SC'ABC 

a fifteen-byte field would be defined, containing five repetitions of the 
ABC EBCDIC character string. Although the implicit length of an 
EBCDIC character is 1 byte, three characters are defined, so the duplica- 
tion factor applies to the three-byte field. 

The operand formats described do not apply when coding address (A- 
type) data constant. An A-type data constant is a single word in length, 
because it contains a Series/1 storage address. 

ACON DATA A(FLCl) 

The statement shown above will define a one-word constant at location 
ACON, containing the address of location FLC1. Note that the name 
of the location whose address you want in ACON is enclosed in paren- 
theses, rather than apostrophes. 

The DATA statement conforms to the rules for the Define Constant (DC) 
instructions in the BPPF Assembler. If you are not familiar with 
defining constants, it is recommended that you review the data 
definition section in the Series/1 Macro Assembler Language 
Reference (SC34-031 7). 
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Here is a summary of the supported data types. The Implicit 
length generated by the assembly of each different type code is 
indicated under Length. 

1. Fixed Point Arithmetic Data 

Type Code Length 

H 1 BYTE 

F 2 BYTES (1 word) 

D 4 BYTES (doubleword) 

H, F, or D type codes define signed, fixed point values of the 
indicated length and are used in Integer arithmetic operations. 

2. Floating Point Arithmetic Data 

Type Code Length 

E 4 BYTES 

L 8 BYTES 

E and L type codes generate standard or extended precision float- 
ing point constants, respectively. Floating point data Is used In 
floating point arithmetic operations (Serles/1 Floating Point 
hardware feature required). 

3. Address Data Definition 

Type Code Length 

A 2 BYTES (1 word) 

The contents of the location defined will contain the address of a 
symbolic program location. 



Hexadecimal/Binary 




Type Code 


Length 


X 


4 BITS 


B 


1 BIT 



These allow definition of binary bit strings in storage, which are 
commonly used in logical operations and when using digital sensor 
I/O (DI/DO/PI). Note: Binary constants (type code B) cannot 
be defined If program preparation is being done using the online 
Program Preparation Facility, $EDXASM. 

5. Character Data 

Type Code Length 

C 1 BYTE/CHARACTER 

Defines EBCDIC characters In storage, for use with EBCDIC I/O 
devices (displays, printers). 
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BUFFER STATEMENT 



READING ASSIGNMENT: IBM Serles/1 Event Driven Executive 
Language Reference (SC34-1706) "BUFFER." 

The BUFFER statement provides a convenient way to define 
contiguous, named, storage areas in a program, for use in I/O operations, 
as work areas, etc. The BUFFER statement reserves space in 
storage, but does not initialize storage to a user-specified value. When 
the statement is assembled, the storage reserved is set to binary zeros, 
and will be zeros when the program containing the statement is 
initially loaded. 

Figure 4-3 illustrates the format for the BUFFER statement, and shows 
what is generated in storage as a result. The label of the BUFFER 
statement is the symbolic name of the first data item. In storage this 
is preceded by two words of control information. The first word is 
called the INDEX, and may be symbolically referenced by the name 
you code in the INDEX= keyword operand of the BUFFER statement. 

INDEX is used with SBIO and INTIME instructions to place data in 
sequential buffer positions automatically, and would not be coded 
unless the buffer being defined were intended for that purpose. 
See "Section 9. Timers" in this study guide for an example of the use 
of the INDEX operand. 

The second word is the count, containing the buffer length you 
specified in the count operand. This count will be the number of words 
or bytes defined, depending on whether you coded BYTES for the item 
operand. 
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TYPE OF ITEMS 
IN THE BUFFER 
(MAY CODE "BYTES", 
OR IF NOT CODED, 
DEFAULTS TO "WORDS' 



label BUFFER count. 



INDEX=name 





SIZE OF 
BUFFER 



NAME ASSIGNED 
TO FIRST DATA 
ITEM 






OPTIONAL 
OPERANDS 



NAME ASSIGNED 
TO INDEX VARIABLE 
F CODED 



^ 



^ 



c 



Figure 4-3. BUFFER statement 















COUNT 


























i- 






. 






















THE NUMBER 
OF WORDS 
(OR BYTES 
IF SPECIFIED) 
EQUAL TO 
"COUNT." 
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TEXT STATEMENT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "TEXT." 

The TEXT statement is used to generate character buffers, and operates 
in conjunction with the terminal instructions READTEXT, PRINTEXT, 
GETEDIT, and PUTEDIT. Figure 4-4 shows the format for the TEXT 
statement, and what is generated in storage. 



label 



TEXT 



message', LENGTH=,CODE= 



ENDMSG TEXT 



RUN ENDED' ,LENGTH=12,C0DE=EBCDIC 




Figure 4-4. TEXT statement 
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In Figure 4-4, the TEXT statement format at Q is shown coded 
at B . The message operand is the text 'RUN ENDED' in this 
example, but may be any character string you wish, up to 254 
characters. The LENGTH= operand is coded as 12, indicating the total 
length of the text buffer. The CODE= operand is EBCDIC, which is 
also the default. The standard internal representation for character data 
is always EBCDIC. The system automatically converts the EBCDIC 
character strings to the code required by a particular terminal. 

The CODE= operand could be coded ASCII. This is for special cases 
where you do not want the system to do any conversion from and to 
EBCDIC, but wish to transmit the exact code pattern in the buffer. 
An example is the graphics support, which drives a device employing 
an ASCII interface where certain ASCII characters perform graphics 
control functions. 

The TEXT statement at Q would generate the storage configuration 
shown just below it. The total storage utilized would be the 14 bytes 
shown by the brackets at Q . The actual text buffer is defined within 
the brackets labeled© , encompassing 12 bytes (LENGTH=12). The 
data buffer is preceded by two bytes of control information, labeled 
Q. The first byte defines the total length of the buffer (hex OC), 
12 bytes. The second byte is the length of this message, nine bytes, 
the total number of characters (including blank characters) in the 
'message' operand. Unused character positions at the end of the 
buffer ©are padded with blanks (EBCDIC for blank = hex '40'). 
The label of the TEXT statement points to the first byte of 
character data © . 

For both input and output operations, the count (second byte at 
location© ) cannot exceed the text buffer length (first byte at© ). 
If you attempt to output a message that is larger than the buffer, or 
read a character string from a device that is longer than the buffer, the 
message will be truncated to fit within the defined buffer length. 

The contents of the character buffer defined by a TEXT statement 
is not confined to the character string that was coded when it was 
assembled. Different messages may be moved into the buffer at dif- 
ferent times during execution of a program. If data is moved into a 
TEXT buffer using the PUTEDIT command, the count byte is auto- 
matically adjusted to reflect the message length. When data is read 
from a terminal with a GETEDIT or a READTEXT command, the 
count reflects the number of input characters read. If a character 
string is moved Into a TEXT buffer by any instructions other than 
these (i.e., MOVE), the count must be adjusted by the user before 
issuing a PRINTEXT referencing that TEXT buffer. 
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1. 


C 


2. 


X 


3. 


B 


4. 


F 


5. 


H 


6. 


D 


7. 


E 


8. 


L 


9. 


A 



DATA DEFINITION REVIEW EXERCISE - QUESTIONS 

1 . Match the type with the data representation 

a Extended precision floating point 

b Address 

c Character 

d Double word fixed point 

e Half word fixed point 

f Full word fixed point 

g Binary 

h Hexadecimal 

i. Standard precision floating point 

2. Using the following instruction 

MSG2 TEXT LENGTH=20 
answer the following questions: 

a. How many characters could be stored in the text buffer 
defined? 

b. How many words would be reserved? 

c. How could you address the first character in the buffer? 

3. How many words are reserved by the following instruction? 

BUF3 BUFFER 16,BYTES 

4. When coding a TEXT statement, if no 'message' is defined 
(LENGTH= only coded), the text buffer will be initialized 
to binary zeros. 

True 

False 
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DATA DEFINITION REVIEW EXERCISE - ANSWERS 

1. a. 8 



b. 


9 


c. 


1 


d. 


6 


e. 


5 


f. 


4 


g. 


3 


h. 


2 


i. 


7 


a. 


20 characters 



b. 1 1 (20 bytes, one for each character, plus 2 bytes (one for 
length, one for count). 

c. By referencing the label MSG2 

3. 10 words are reserved; 8 for the 16 data positions, and the two 
control words which precede the data. 

4. False. Undefined text buffer locations are initialized to 
EBCDIC blanks (hex 40). 



r 
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Section 5. Data Manipulation 



INTEGER ARITHMETIC 



OBJECTIVES: After successful completion of this topic, the student 
should be able to: 

1. Understand the Event Driven Executive arithmetic instructions 
which operate on signed integer variables 

2. List the Event Driven Executive arithmetic instructions which 
operate on floating point data 

3. Use the Event Driven Executive data movement instructions to: 

a. Replace the contents of one variable with that of another 

b. Replace the contents of a variable with the address of another 

c. Replace the contents of a data field with the contents of 
another data field 

4. Determine the result of executing any of the Event Driven Execu- 
tive logical instructions, given the values represented by operandi 
and operand2 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "Data Manipulation", "Data 
Representation", "Mixed Precision Operations", "ADD", "ADDV", 
"SUBTRACT", "MULTIPLY", "DIVIDE." 

Figure 5-1 shows the basic format of instructions that operate on 
integer arithmetic variables. 




ADD I 

SUBTRACT I 

ADDV opndl,opnd2',count,RESULT=,PREC= 

MULTIPLY ! 



I ^ 



optional; 



1 DIVIDE i OPTIONAL 



MUST BE CODED 
Figure 5-1 . Integer arithmetic instruction format 

Data flow is from opnd2, to opndl ; in the ADD or SUBTRACT 
instructions, the data represented by opnd2 is added to or subtracted 
from the data represented by opndl, and the result of the 
operation replaces the contents of the location specified by opndl. 
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Optional Operands 



In the MULTIPLY or DIVIDE instructions, the data in opndl is 
multiplied or divided by the data in opnd2, and the product or 
quotient replaces the contents of opndl (for DIVIDE; the remainder 
is stored in the task code word, and will be overlaid by the next 
DIVIDE, I/O or floating point operation). 



The optional operands (count, RESULT=, and PREC=) allow the appli- 
cation programmer to control the number of variables involved in the 
operation, where the result of the operation should be placed, and to 
specify the size of the variables (word, doubleword) used. The following 
examples illustrate how the optional operands affect instruction 
execution. An ADD operation is used as an example, but the principles 
also apply for SUBTRACT, MULTIPLY, and DIVIDE. 

EXAMPLEl ADD VAL1,C0NW0RD 

This first example uses no optional operands, and is the most basic 
form. The word at location CONWORD will be added to the word at 
location VAL1. The results of the operation will replace the contents 
of VAL1. Both VAL1 and CONWORD are assumed to be single pre- 
cision (word-length) signed integer variables, because word-length is the 
default when no other precision is specified. 

EXAMPLEl ADD VALl, CONWORD, 5 

The count operand is coded as a 5. The count operand references 
opndl, and specifies how many variables, beginning at the location 
specified in opndl, the contents of opnd2 should be added to. In the 
example shown, the word at location CONWORD would be added to 
the word (still the default precision) at location VALl, to the word at 
location VALl +2 (two bytes = one word), at VALl +4, and so on 
through location VALl +8. Each of the words in the five word field 
beginning at location VAL1 would be increased by the value of the 
contents of location CONWORD. 

EXAMPLEl ADD VALl, CONWORD, 5, RESULT=RFIELD 

Without changing anything else, the keyword operand RESULT= 
has now been added. This statement will execute the same way as did 
the previous example except that the results of the operation will be 
placed in a five-word field beginning at location R FIELD. The five 
words beginning at location VALl will remain unchanged. 

The only remaining optional operand is the keyword PREC=, which 
allows the programmer to specify the precision of the opndl and opnd2 
variables. Again using our example, if the field of data beginning at 
location VALl were double precision integers, and we wanted to add a 
single precision integer at location CONWORD to each of them, 
PREC=D would be coded. 

EXAMPLEl ADD VALl, CONWORD, 5, RESULT=RFIELD,PREC=D 
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CThe results (double precision integers) would be placed in a ten word 
] field beginning at location RFIELD, leaving the original contents of 

\/AI 1 iinrlic+iirhoH 



VALl undisturbed. 

The D in PREC=D signifies that opndl is double-precision. DD would 
have indicated that both opndl and opnd2 were double precision. See 
"Mixed Precision Operations" in the Language Reference manual for 
allowable opnd1/opnd2 precision combinations. 

Thus far, the count optional operand referred to opndl only. The 
vector addition capability is an exception to that rule. The ADDV 
statement adds the corresponding components of two vectors 
together, and therefore the count operand specifies the number of 
components in both vectors (opndl and opnd2). 



FLOATING POINT ARITHMETIC 



The format for Floating Point instructions is similar to that for the 
arithmetic instructions handling integer variables, except that the 
optional count operand is not allowed. Floating point operations 
involve the two discrete values represented by opndl and 
opnd2 only; neither may be vectors. 




FADD 

FMULT opndl, opnd2 

FDIVD 



RESULT=,PREC= 



OPTIONAL 



MUST BE CODED 
Figure 5-2. Floating point arithmetic instruction format 

The floating point instructions are not software simulations of floating 
point hardware; the Series/1 Floating Point hardware feature must 
be installed to utilize the floating point capability. 

Support for both standard and extended precision variables 
(PREC= operand), and all precision combinations are allowed. 

For an example of the use of floating point instructions, see Example 6 
in the Language Reference, SC34-1706. 
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DATA MOVEMENT INSTRUCTIONS 



READING ASSIGNMENT: IBM Serles/1 Event Driven Executive 
Language Reference (SC34-1706), "MOVE", "MOVEA." 

The MOVE statement has the following format: 



label 



OPTIONAL 



MOVE opndl,opnd2 



count 

— or— 

, precision 

— or— 

(count, precision) 

V , ' 

OPTIONAL 



MUST BE CODED 
Figure 5-3. MOVE instruction format 

Unlike the integer and floating point arithmetic instructions, the 
RESULT= optional keyword operand is not used; the data specified 
by opndl is always replaced by that represented by opnd2. The 
following statement. 



MOVE 



OLDATA,NEWDATA 



would replace the word (default precision) at location OLDATA with 
the word at NEWDATA. 

The same operation, coded with the count operand=3, 

MOVE OLDATA, NEWDATA, 3 

would move the three words starting at location NEWDATA into the 
three words starting at location OLDATA. 

For MOVE statements, precision is indicated by the keywords BYTE, 
WORD (default) or DWORD (doubleword). If count is not coded 
(default count = 1), then precision is coded by itself. If count is 
coded, precision is included as a sublist element in the count operand. 
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Neither count nor precision 
coded; count default=1; 
precision default=WORD 



I 



MOVE OLDATA,NEWDATA 

MOVE 0LDATA,NEWDATA,5 

MOVE OLDATA,NEWDATA, DWORD 

MOVE 0LDATA,NEWDATA,(5,DW0RD) 



count alone 
coded; precision 
default=WORD 



precision alone coded; 
count default=l 



count and precision 
both coded; precision 
included as a sublist 
element in count operand 



Figure 5-4. MOVE optional operands 



Move operations move data from a field of specified length, to a field 
of equal length, so count applies to both opndl and opnd2. 

The following examples Illustrate the MOVE Instruction optional 
operand variations. Each of the Instructions Is logically equivalent, 
moving four bytes of data from opnd2 to opndl. 

MOVE 0LDATA,NEWDATA,{4,BYTE) 

MOVE 0LDATA,NEWDATA,2 

MOVE 0LDATA,NEWDATA,(2,W0RD) 

MOVE OLDATA,NEWDATA, DWORD 

MOVE 0LDATA,NEWDATA,(1, DWORD) 

The MOVE A Instruction moves the address of the location specified In 
opnd2 into the location specified by opndl. 



MOVEA 



DATADRS,DATA 
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In the example shown, the address of location DATA replaces the 
contents of location DATADRS. No optional operands are allowed 
with the MOVEA statement, because: 

a. opndl is always the target of the move, so RESULT= is 
not valid 

b. the data being moved is a Series/1 storage address, which is, 

by definition, word-length; precision is therefore always WORD 
(no PREC= coded) 

c. only a single address at a time is moved, so count is always 
= 1, and is therefore not coded. 



LOGICAL INSTRUCTIONS 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "AND", "lOR", "EGR", 
"SHIFTL", "SHIFTR." 

The logical instructions AND (AND), OR (lOR), and exclusive OR 
(EOR) operate upon selected bits within a bit field. Opnd2 operates on 
opndl in the manner summarized in Figure 5-5. 



AND (AND) 
OPERAND 2 fo ^^l 1 



OPERAND 1 folO 1 



f 



RESULTS rolv 



IF A BIT IS A 1 IN THE SECOND 
OPERAND, AND THE CORRES- 
PONDING BIT IS A 1 IN THE 
FIRST OPERAND, THAT BIT Wl LL 
BE A1 IN THE RESULT. 



OR (lOR) 
OPERAND 2 \~0\{^ 0~ 



OPERAND 1 rO ^O 1 

fol^i 1 1 



IFABITISA1 IN EITHER THE 
SECOND O/? THE FIRST OPERAND, 
THE CORRESPONDING BIT IN 
THE RESULTWILLBE A1. 



RESULTS 



Exclusive OR (EOR) 
OPERAND 2 fO^p 1 



J L 



OPERAND 1 fol^l 1 



RESULTS rp ^^O 1 1 



IF ABIT ISA 1 IN ONEOFTHE 
TWO OPERANDS, BUT NOT IN 
THE OTHER, THE CORRESPOND- 
ING BIT IN THE RESULT WILL 
BE A1. 



NOTE: RESULTS OF AND, lOR, EOR OPERATIONS WILL REPLACE THE 

CONTENTS OF OPERAND 1, OR WILL BE PLACED IN THE LOCATION 
SPECIFIED IN THE RESULTS= OPERAND. IF IT IS CODED. 

Figure 5-5. AND/OR/exclusive OR 
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c 



The instruction format for AND, lOR, and EOR is shown in Figure 5-6. 
As with IViOVE operations, precision may be BYTE, WORD (default), or 
DWORD. The precision applies to opndl, opnd2, and to RESULT=, 
if coded. The count optional operand applies to opndl and 
RESULT= only; count for opnd2 is always =1. 



label 



AND 
lOR 
EOR 



opndl, opnd2 



OPTIONAL' ' 

MUST BE CODED 

Figure 5-6. Logical instruction format 



count 

— or— 

, precision ,RESULT= 

— or— 

(count, precision) 

OPTIONAL 



If RESULT= is coded, the contents of opndl are unchanged by the 
operation. The following illustrates the use of the optional operands. 



AND 



XDATA,ZDATA 



Since count, precision, and RESULT= are not coded, count defaults 
to 1, precision defaults to WORD, and the contents of XDATA will 
be replaced by the word-length bit-field resulting from the AND 
of the 16 bits in the word at ZDATA with the 16 bits in the word at 
XDATA. 



AND 



XDATA, ZDATA, 3 



The contents of XDATA, XDATA+2, and XDATA+4 will be replaced 
by the results of the AND of the 16 bits in the word at ZDATA with 
each of the 16 bits beginning at XDATA. Note that the same word at 
ZDATA is consecutively ANDed with the three-word bit field beginning 
at location XDATA. The precision {default=WORD) determined 
how many bits at a time to AND (opnd2 size), and the count operand 
how many consecutive groups of bits of that size to perform the 
operation against 



AND 



XDATA, ZDATA, (3, BYTE) 



The above is the same as the operation shown before, except that the 
8 bits specified in opnd2 (BYTE precision) are successively ANDed 
against the three 8-bit groups In opndl, beginning with the byte at 
location XDATA. 
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AND 



XDATA,ZDATA,(3,BYTE),RESULT=YDATA 



When the statement above is executed, the three bytes, beginning at 
location YD ATA, will be replaced by the results of the AND of the 
byte at location ZDATA with the three bytes in XDATA, XDATA+1, 
and XDATA+2. 

Event Driven Executive logical instruction capability also includes 
logical shift operations, for both shift left (SHIFTL) and shift right 
(SHIFTR). (See Figure 5-7.) Logical shifts, like the other logical 
instructions, operate on bit-fields (bit-strings). 



label 



OPTIONAL N. 



SHIFTR 
SHIFTL 



opndl,opnd2 



MUST BE CODED 
Figure 5-7. Shift instruction format 



count 



-or- 

I , precision ,RESULT= 

I -or- 

I (count, precision) 



I 
I 



OPTIONAL 



In shift operations, opnd2 is coded as an absolute value or as a variable 
name. The absolute value, or the contents of the variable, contains the 
shift count (the number of bit positions, to the right or left, that the 
contents of the bit field which begins at location opnd1, should be 
shifted). 

The optional operands have the same meaning, and are coded in the 
same way, as for AND, lOR, and EOR (note that if opnd2 is a variable 
name, that variable has the same precision (BYTE,WORD,DWORD) 
as the variable opndl ). 
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A SHIFTL instruction shifts bits out of the high-order (most significant) 
position of a bit field, and fills vacated low-order (least significant) bit 
positions with zeroes. Similarly, SHI FTR shifts bits out of the low- 
order position, and zero-fills vacated high-order positions. Figure 5-8 
illustrates the operation of both SHIFTL and SHI FTR. 



H-^ 



FIRSTOP 



SECONDOP 



SCNT 

FIELDA 

FIELDB 



SHIFTL 
■^MOVE 
SHIFTR 



DATA 
DATA 
DATA 



FIELDA, 5 
SCNT,1 
FIELDB, SCNT 



C0UNT=5 BIT POSITIONS 

_^WORD PRECISION (default) 



^Word at SCNT used 
for shift count 



F'O' 

B' 1111000011110000' 

B' 0001111000000000' 



Figure 5-8. Shift operation 



Before execution of the Shift Left at FIRSTOP, the contents of 
FIELDA and FIELDB are exactly as coded 



^ Shifted out of 
high order position 



Q After execution of the Shift Left at Fl RSTOP; 

FIELDA =.0001 1110 OOOo"oOOO 

nil 

B After execution of the MOVE operation, location SCNT=1 
Q After execution of Shift Right at SECONDOP, 

FIELDA = 0001 1110 0000 0000, unchanged, 

and FIELDB =1)000 1111 0000 0000-,^ ^., ^ 

X *0 shifted out of 

zero fills'' low order bit 

vacated position position 



zeros filled in 
vacated bit positions 
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DATA MANIPULATION REVIEW EXERCISE - QUESTIONS 



1. Fill in the value for X, Y, and Z after execution of each of the 
instructions below. In each case, assume that before execution, 
X=20, Y=30, and Z=0. 



ADD X,Y 



Answers: X= Y= Z= 



b. ADD X,Y,RESULT=Z 



Answers: X= Y= Z= 



c. ADD X,50 



Answers: X= Y= Z= 



2. Analyze the two arithmetic operations below, and explain how 
they would differ when executed. 



a. ADD X,Y,2 b. ADDV X,Y,2 



ANSWER:. 
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Analyze the two data movement operations below, and explain 
how they would differ when executed. 



a. MOVE 
ANSWER:. 



X,Y 



b. MOVEA 



X,Y 



4. Below Is a coding example using all five logical instructions. Each 
instruction uses the "RESULT=" optional keyword operand to place 
the result in a different location (opndl is undisturbed). Fill in 
(in binary) what the "RESULT=" locations would be after execution 
of the coding example. 



XDATA 
ZDATA 



AND 

lOR 

EOR 

SHIFTR 

SHIFTL 



XDATA , ZDATA , BYTE , RESULT=ANDRSLT 
XDATA, ZDATA, BYTE, RESULT=IORRSLT 
XDATA , ZDATA , BYTE , RESULT=EORRSLT 
ZDATA, 7, BYTE, RESULT=RITERSLT 
XDATA, 3, BYTE, RESULT=LEFTRSLT 



DATA 
DATA 




B 
B 


11010010' 
10011001' 


ANSWERS: 
• After execution 


/ 






a. 


ANDRSLT= 


B' 






b. 


IORRSLT= 


B' 






c. 


EORRSLT= 


B' 






d. 


RITERSLT= 


=B' 






e. 


LEFTRSLT= 


= B' 







Data Manipulation 5-1 1 



DATA MANIPULATION REVIEW EXERCISE - ANSWERS 



1. a. X50 Y30 ZO ( 
b. X20 Y30 Z5g 

c. X70 Y3g zg 

2. Example a. (ADD operation) would add the contents of storage 
location "Y" to storage location "X" and to storage location 
"X+2". The "count" operand (2) applies to opndl only. 
Example b. (ADDV operation) would add the contents of storage 
location "Y" to storage location "X", and the contents of storage 
location "Y+2" to the contents of storage location "X+2". The 
"count" operand of the ADDV instruction applies to both opndl 
and opnd2 (also for MOVE). 

3. Example a. (MOVE operation) would replace the contents of 
storage location "X" with the contents of storage location "Y" 
(move Y to X). Example b. (MOVEA operation) would replace 
the contents of storage location "X" with the address of the 
storage location "Y" (move the address of Y to X). 

4. a. ANDRSLT=B' 10010000' 

b. IORRSLT=B' 11011011' 

c. E0RRSLT=B'01001011' 

d. RITERSLT=B' 00000001' 

e. LEFTRSLT=B' 10010000' 
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Section 6. Queue Processing 



J 



OBJECTIVE: After completing this topic, the student should be 
able to: 

1. Define an empty or a full queue 

2. Add entries to a queue 

3. Retrieve the oldest entry from a queue 

4. Retrieve the newest entry from a queue 

READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "Queue Processing." 

The queuing instructions discussed in this section are used to define 
queues and access entries in queues. The size of a queue (the number 
of entries it can hold) is specified by the user. A queue entry is one 
word in length. The contents of this word may comprise the queue 
entry in its entirety, or as in the examples used In this section, may 
be the address of a larger data area (buffer). 

A useful example of queue definition and processing is buffer pool 
management. If several tasks within an application program have the 
possibility of performing I/O operations, a queue of I/O buffers 
(buffer pool) can be established. Using the queue processing 
instructions, a task requiring an I/O buffer obtains it from the 
pool, and, when the I/O has completed, returns It to the pool. No 
physical movement of the buffer is Involved; the queue entry that is 
acquired and returned is actually the address of the buffer in storage. 

Another example of the use of queue processing is a "data spooling" 
operation, where multiple units of data are placed in a direct access 
data set, with the record numbers of the first record of each unit stored 
as a data element (entry) in a queue for later processing. In this 
instance, the single-word queue entry is the queued data item itself, 
rather than a pointer to a storage location or buffer. 
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DEFINEQ 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "DEFINEQ." 

For this discussion, a queue is the system mechanism and control 
blocks necessary to logically connect and manage a chain of queue 
entries. Figure 6-1 shows the format of the DEFINEQ statement, 
which is used to establish a queue. 



label DEFINEQ COUNT= 




MUST BE CODED 
Figure 6-1. DEFINEQ format 

The label of the DEFINEQ statement is a required field. It is the 
symbolic name of the queue, and will be used by queue processing 
instructions to access the queue. The COUNT= keyword operand 
(coded as an integer value) determines the number of Queue Control 
Elements (QCEs) and therefore, the possible number of associated 
buffer pool elements the queue may reference. QCEs are three-word 
system control blocks, which are logically (contain address pointers) 
chained together in active or free QCE chains. QCEs in the active 
chain include data entries; free chain QCEs contain no data entries, 
and are connected to other free QCEs. 

In addition to QCEs, the DEFINEQ statement also generates a single 
Queue Control Block (QCB). The QCB is three words long, and the 
first word is assigned the label of the DEFINEQ statement. The 
QCB contains address pointers to the active and free chains of 
QCEs. When an entry is added to a queue, the QCB address pointers 
are adjusted to remove a QCE from the free chain and attach it to 
the active chain. 

SIZE= is an optional keyword operand. It may be coded to cause 
the generation of a pool of data buffers associated with the queue 
being defined. The number of such buffers will equal that specified 
in the COUNT= operand. The size of each buffer (in bytes) is 
specified by the integer value coded in the SIZE= operand. If 
SIZE= is not coded, no buffer pool will be generated, and all QCEs 
will initially be defined to be in the free chain (empty queue). If 
SIZE= is coded, all QCEs will be in the active chain (full queue), 
and the entry in each active QCE will point to one of the buffers in 
the buffer pool. 
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In Figure 6-2, the SIZE= operand is not coded, so an empty queue 
is defined (all QCEs in free chain). In figure 6-2, and in the rest of the 
illustrations in this section, QCEs in the free chain are shown as shaded. 



QTHREE DEFINEQ C0UNT=3 



QTHREE L^ 



QCB 
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Figure 6-2. Empty queue 

No entries are in the queue, but there is space (free QCEs) available 
for the addition of three entries. 

In Figure 6-3, a full queue (all QCEs in active chain, with queue 
entries pointing to buffer pool elements) is defined. Each buffer pool 
element is four bytes in length (SIZE=4). No more entries may be 
added to this queue, as all QCEs are already active. 
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Figure 6-3. Full queue 



LASTQ/FIRSTQ/NEXTQ 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference {SC34-1706), "NEXTQ", "FIRSTQ", "LASTQ.' 

The queue processing instructions allow the user to add (NEXTQ) or 
retrieve (LASTQ, FIRSTQ) entries in a queue defined by the 
DEFINEQ statement. The format for all three queue processing 
instructions is similar: 



label 



FIRSTQ 

NEXTQ 

LASTQ 



qnamejoc, FULL= 
I EMPTY= 



OPTIONAL MUST BE CODED 

Figure 6-4. Queue processing instruction format 



OPTIONAL 



FIRSTQ and LASTQ are used to retrieve entries from a queue; NEXTQ 
places an entry in a queue. The label of a DEFINEQ statement is 
coded as qname, specifying which queue is being accessed. 
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" \ The loc operand is the label of a one-word storage location. This word 

y will be set to the contents of the entry being retrieved from the queue 

by a FIRSTQ or LASTQ instruction. Before executing a NEXTQ 
instruction, the user must ensure that this word contains the entry 
(data item, such as a record number; or address of a buffer pool 
element) being added to the queue. 

The EMPTY= keyword operand is coded as the label of the instruction 
that will receive control if the queue referenced by a Fl RSTQ or 
LASTQ instruction has no active entries. FULL= performs the same 
function for the NEXTQ instruction in the event there is no room in 
the queue to add an entry. If EMPTY= or FULL= is not coded, and 
the queue is erroneously empty or full, execution will continue with 
the instruction following the Fl RSTQ/LASTQ or NEXTQ. A +1 
will be returned in the task code word (taskname), and may be 
checked by the user. 

Entries are placed in a queue one at a time. Therefore, queue entries 
differ in their relative age, as some are queued before others. Both 
F I RSTQ and LASTQ retrieve entries from a queue, but they differ 
in the age of the entries they retrieve. 

LASTQ retrieves the last, and therefore the most recently entered, 
entry in a queue. This is often called "Last In, First Out", or 
LIFO queue processing. It is also referred to as stack processing. 
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QUEUE PROCESSING REVIEW EXERCISE-QUESTIONS 



1. Including all control blocks, how many bytes of storage will be 
reserved by the DEFINEQ statement below? 

QEXAMP DEFINEQ C0UNT=5,SIZE=256 

Answer: bytes 

2. What instruction would you execute to: 

a. Retrieve the oldest entry in a queue 

b. Add an entry to a queue 



c. Retrieve the most recent entry in a queue 



Figure 6-4 shows the format for the Queue Processing instructions. 
What optional keyword operand would be used to branch to a user 
routine: 

a. When you attempt to retrieve a queue entry and there are no 
active entries 

b. When you attempt to add an entry to a full queue 



Queue Processing 6-7 



QUEUE PROCESSING REVIEW EXERCISE-ANSWERS 



1. 6 QCB 3 words, 2 bytes/word 

30 QCEs 5 QCEs, 3 words, 2 bytes/word 

1280 BUFFERS 5 of 256 bytes each 
1316 bytes 

2. a. FIRSTQ 

b. NEXTQ 

c. LASTQ 

3. a. EMPTY = 
b. FULL = 



v„,. 
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Section 7. Program Control 



OBJECTIVES: Upon successful completion of this topic, the student 
should be able to: 

1. Explain the use and execution of subroutines in an application 
program 

2. Incorporate Assembler language routines in an Event Driven 
Executive program 



SUBROUTINES 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "SUBROUT", "CALL", "RETURN." 

In many programs, there are certain functions that are required 
repeatedly at different points in the program's execution. Examples 
might include conversion of data from one code to another or a 
particular sequence of arithmetic calculations. 

Rather than code the sequence of instructions that perform the desired 
function each time the program needs that function, the function is 
coded once, and defined as a subroutine. The subroutine can then be 
entered and executed from as many different points in the application 
program as required. 



SUBROUT STATEMENT 



Subroutines are defined using the SUBROUT statement whose format 
is shown in Figure 7-1. 



label I SUBROUT namei ,parl, par5 



OPTIONAL MUST BE CODED 
Figure 7-1 . SUBROUT format 



OPTIONAL 



The name operand is coded with the symbolic name of the subroutine 
and will be referenced by other instructions. The label field is 
optional, and should not be confused with the subroutine name 
specified in the name operand. 
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CALL STATEMENT 



Pari through par5 are names of parameters that may be passed to 
the subroutine when it is entered. 

V. 



The format of the CALL statement is shown in Figure 7-2. The 
CALL is used to enter a subroutine defined in a SUB ROUT 
statement. 



label I CALL namel,parl, par5 

OPTIONAL MUST BE CODED OPTIONAL 
Figure 7-2. CALL format 



The name operand is coded with the symbolic name specified in the 
name operand of the SUB ROUT statement defining the subroutine 
you wish to execute. Pari through par5 may be coded as single 
precision integer values, as the symbolic names (labels) of single 
precision integer values, or as the addresses of program variables or 
data areas. 



PASSING SUBROUTINE PARAMETERS 



Figure 7-3 illustrates basic subroutine operation. Note that the 
CALL at location START is a call to CALC, not to SUB1, the label 
on the SUB ROUT statement. The last executable statement in 
this and every subroutine is a RETURN. The RETURN instruction 
provides the linkage back to the calling task, where execution resumes 
at the instruction following the CALL. Subroutines execute as part 
of, and at the same priority as, the calling task. Subroutines are not 
re-entrant, so if a subroutine is called from multiple tasks, ENQ and 
DEQ should be used to ensure serial execution. 
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SUBEXAMP 
START 



PROGRAM 
CALL 



START 
CALC 





PROGSTOP 




INTEGERA 


DATA 


F'lO' 


INTEGERS 


DATA 


F'15' 


SUM 


DATA 


F'O' 


SUBl 


SUBROUT 


CALC 




ADD 


INTEGERA, INTERGERB,RESULT=SUM 



ENDIT 



RETURN 

ENDPROG 

END 



Figure 7-3. Subroutine operation 

The subroutine CALC in Figure 7-3 adds two integer values together 
and stores the result at location SUM. Since CALC is part of 
program SUBEXAMP, all labels within the progrann are known to 
the subroutine, and may be referenced by instructions within the 
subroutine. In this example, location SUM would contain 25 after 
the subroutine has been executed. 

When a subroutine uses specific labels in the program, the data that 
the subroutine will operate on must be moved into the storage 
addresses represented by those labels before the subroutine is called. 
The same result can be achieved more easily by using the parameter 
passing capability. Parameters may be actual values (integer numbers), 
or may take the form of pointers to data that the subroutine will 
be using. 

In figure 7-4, the SUBROUT statement at location SUBl specifies two 
parameters, XVAL and YVAL. The names used to define parameters 
In SUBROUT statements must be unique throughout the program 
(cannot appear in the label field of any statement). They are 
positional symbolic references to parameters that are passed in the 
CALL statement. 
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SUBEXAMP 
START 



PROGRAM 
CALL 



START 
CALC,50,SUM1 



C2 



CALL 



CALC,SUM1,SUM2 





PROGSTOP 




INTEGERA 


DATA 


F'lO' 


INTEGERS 


DATA 


F'15' 


SUMl 


DATA 


F'O' 


SUM2 


DATA 


F'O' 


SUBl 


SUBROUT 


CALC,XVAL,YVAL 


Al 


ADD 
RETURN 
ENDPROG 
END 


INTEGERA, XVAL,RESULT=YVAL 



Figure 7-4. Integer parameters 

In the first CALL (location START), the first parameter is the single 
precision integer value 50. This corresponds to the first parameter 
defined in the SUBROUT statement, XVAL, as does program location 
SUMl to the second parameter definition YVAL. When the ADD 
instruction at location Al executes as a result of this call, the value 
50 will be substituted when XVAL is referenced, and location SUMl 
will be used in place of YVAL. Location SUMl will be set to 60, 
the sum of INTEGERA and 50. 

The second CALL at C2 will result in 70 being put in location SUM2, 
the sum of SUMl and INTEGERA. Notice that although 
INTEGERA is used by the subroutine, it need not be passed as a 
parameter, since it does not change from CALL to CALL. 

Up to this point, the parameters illustrated have been restricted to 
single precision integer values. By passing an address of a data area 
as a parameter, and utilizing the software registers (#1, #2) within 
the subroutine, any data area or data array may be accessed. 

In Figure 7-5, the address of the data area SUMAREA is passed as the 
first parameter of the CALL (label is enclosed in parentheses to 
specify address rather than content of address). When the subroutine 
executes the address is loaded into software register #1. The results 
of the ADD operations are moved into SUMAREA using the contents 
of #1 as a base address. After execution, SUMAREA will contain 50, 
and SUMAREA+2 will contain 25. 
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SUBEXAMP 
START 



PROGRAM 
CALL 



START 
CALC,(SUMAREA),40,INTERGERB 





PROGSTOP 




SUMAREA 


EQU 


• 




DATA 


2F'0' 


INTEGERA 


DATA 


F'lO' 


INTEGERS 


DATA 


F'15' 




SUBROUT 


CALC,ADDRSLT,XVAL,YVAL 




MOVE 


#1,ADDRSLT 




ADD 


INTEGERA, XVAL,RESULT=S1 




MOVE 


(0,#1),S1 




ADD 


INTEGERA, YVAL,RESULT=S1 




MOVE 


(2,#1),S1 




RETURN 




SI 


DATA 

ENDPROG 

END 


F'O' 



Figure 7-5. Address parameter 

When employing this technique, you should keep in mind that 
the software registers used by subroutines are those associated 
with the calling task, and therefore, the subroutine may be 
required to save them on entry and restore them to their original 
values before returning. 

Note: If a subroutine is assembled as a separate module for later 
link editing, the subroutine name must be declared in an ENTRY 
statement. 



USER STATEMENT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference {SC34-1706), "USER." 

At some time you may require a function not provided by the Event 
Driven Executive. Such functions can be coded in Series/1 assembler 
language (assuming that you have the appropriate assembler language 
background) and included in an Event Driven Executive program 
as a user exit routine. The USER statement provides the linkage 
between the Event Driven Executive code and the Series/1 assembler 
language routine. 
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1 ! 



label I USER namej ,PARM=(parml,. . .parmn) 
OPTIONAL MUST BE CODED OPTIONAL 

Figure 7-6. USER format 



The name operand is coded as the label of the entry point (label of 
first executable instruction) of the assembler language routine. The 
PARM= keyword operand is coded as a list of parameters, with each 
parameter as a sublist element. 

When executing Event Driven Executive code, the user is limited to the 
two software registers, #1 and #2. In Series/1 assembler language, the 
hardware registers are available. Since the Event Driven Executive 
system uses these hardware registers also, certain conventions must be 
observed when execution switches from Event Driven Executive code 
to Series/1 assembler language and back again. First, hardware 
register 2 (R2) is always pointing to the Task Control Block of the 
task currently in execution, and must not be disturbed. Second, hard- 
ware register 1 (R1) is used by the system to provide linkage to and 
from Event Driven Executive instructions. When a user exit routine 
is entered (branched to by a USER instruction), R1 is pointing to the 
next instruction following the USER statement, where Event Driven 
Executive language execution will resume when the assembler 
language routine completes. If parameters are passed by the USER 
statement (PARM= coded), R1 will be pointing to the location con- 
taining the first parameter. Before exiting from the assembler 
language code, the user must increment R1 past all parameters so 
that it points to the Event Driven Executive instruction following the 
USER statement. 

The program in Figure 7-7 includes the user exit routine SI CODE. 
When the USER statement at location START is executed, a branch 
to label SI CODE is performed. 

Two parameters are coded in the PARIVI= parameter list of the USER 
statement. As with the CALL statement, each parameter is one word 
in length, consisting of an integer value or the address of a program 
location. Upon entry to SI CODE, R1 is pointing to the first para- 
meter, which contains the integer value 9. The MVW at location 
S1C0DE moves the integer value to location FRSTPARM. 

The second parameter is the address of program location XVAL. 
Using the indirect addressing capability, R1 is again used to move 
the parameter into the subroutine. 
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USERXAMP 


PROGRAM 


START 


START 


USER 


S1C0DE,PARM=(9,XVAL) 


Al 


ADD 


P3,FIVEB 





PROGSTOP 




XVAL 


DATA 


F'O' 


P3 


DATA 


F'O' 


FIVEB 


DATA 


F'O' 



SICODE 
GET2 



(R1,0),FRSTPARM 
(R1,2)*,SECDPARM 



UPDATE 


ABI 


4,R1 


OUT 


B 


RETURN 


FRSTPARM 


DC 


F'O' 


SECDPARM 


DC 

ENDPROG 

END 


F'O' 


Figure 7-7. User exit routine 





To go back to Event Driven Executive code from a user exit routine, 
you must branch to label RETURN (B RETURN), as shown at location 
OUT. The system routine RETURN expects to find R1 pointing to the 
next Event Driven Executive instruction following the USER statement. 
The ABI instruction, at location UPDATE, increments R1 past the 
two words in the parameter list, so that it points to the ADD 
instruction at location Al. 
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User exit routines can only be assembled by $S1 ASM (Series/1 macro 
assembler) or host macro assemblers. To incorporate a user exit 
routine into a program prepared using the Program Preparation 
Facility, the routine must be first assembled using $S1 ASM or the 
host assembler, and the resulting object module linked to the Event 
Driven Executive main program using $LINK. The user exit 
routine entry point should be defined in an ENTRY statement, and 
the same entry point must be coded in an EXTRN statement in the 
main program with which the routine will be linked. 
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PROGRAM CONTROL REVIEW EXERCISE - QUESTIONS 



1 . What statement is coded to transfer control to a subroutine 
written in Event Driven Executive language? 

Answer: 

2. Event Driven Executive subroutines begin with a 



statement, and the last statement to be executed must be a 
statement. 

3. Why can't user exit routines be assembled using $EDXASM? 

Answer: 



4. How does executing a subroutine differ from executing a 
secondary task? 

Answer: 



What statement is used to transfer control to a user exit 
routine? 

Answer: 

How can you pass more than five parameters to an Event 
Driven Executive subroutine? 

Answer: 
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PROGRAM CONTROL REVIEW EXERCISE - ANSWERS 

1. CALL 

2. SUBROUT, RETURN 



3. User exit routines are written in Series/1 assembler language, 
and the $EDXASM assembler can assemble Event Driven 
Executive language only. User exit routines are assembled 
using the Series/1 Macro Assembler $S1 ASM, or a host macro 
assembler. 

4. A secondary task executes concurrently with the attaching 
task, and may be run at a different priority. A subroutine 
executes on the priority of the calling task, and "In-line" with 
the execution of the calling task. 

5. USER 

6. Use one of the five parameters to pass the address of a data 
area to the subroutine. The data area can contain as many 
additional parameters as required. 
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Section 8. Program Sequencing 



GOTO STATEMENT 



OBJECTIVES: Upon successful completion of this topic, the student 
should be able to: 

1. explain the operation and use of 

a. unconditional GOTO 

b. indirect GOTO 

c. computed GOTO 

2. define an IF/THEN/ELSE/ENDIF structure 

3. define a DO/EN DDO structure 

4. explain the use of relational statements with IF and DO statements 

5. combine IF, DO, and GOTO statements in logical code sequences 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "Program Sequencing", "GOTO." 

Almost all programs have multiple execution paths. A different 
sequence of execution may be necessary because of the characteristics 
of the input data, the results of a calculation, or the occurrence 
of an exception or error condition. One of the Event Driven 
Executive instructions providing the means to transfer control to an 
alternate section of code is the GOTO statement. 

Figure 8-1 is an example of the most basic form of the GOTO state- 
ment. This is an unconditional GOTO, used to branch around a 
section of non-executable code (e.g., data definitions) that are 
imbedded within the executable code. 
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PROGl 
START 



TABLEl 



—^NEXTSTEP 



EXECUTION 



PROGRAM 



START, 100 



IGOTO 
DATA 
DATA 
ADDV 



NEXTSTEP 
5F'256' 
C'000256' 
TABL1,V1,5 



V 



ENDPROG 
END 



Figure 8-1. Unconditional GOTO 



Control is transferred from the GOTO statement to the statement at 
location NEXTSTEP, skipping over the two DATA statements which 
start at TABLEl. 

Figure 8-2 illustrates another form of GOTO. In this example, the 
operand is enclosed in parentheses, indicating an indirect GOTO. 
During PR0G1 program execution, but prior to executing the 
GOTO instruction, the address of the desired "branch to" location 
(Address of NEXTSTEP) Is moved Q into location BRNCHADR Q 

BRNCHADR is the name defined within parentheses in the operand 
of the GOTO statement Q. When the GOTO is executed, control 
is transferred to the instruction at NEXTSTEP Q, indirectly 
through the contents of BRNCHADR. 

The indirect GOTO can serve as an unconditional branch to any 
label in a program, as long as the address of the desired destination 
is first moved into the indirect address location coded as the operand 
of the GOTO. 
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PROGl 
START 



PROGRAM 



START, 100 



^MOVEA 



BRNCHADR, NEXTSTEP 



\ 



RNCHADR 



^GOTO 
DATA 



(BRNCHADR) 
F'O' 



IX 



NEXTSTEP 



ADD 



ZVALU,BVALU 



ENDPROG 
END 



Figure 8-2. Indirect GOTO 



A third form of GOTO statement is the computed GOTO, whose format 
is shown in Figure 8-3. 



label 

OPTIONAL 



GOTO (locOJocl, locn), index 



MUST BE CODED 
Figure 8-3. Computed GOTO format 



In the first operand, locO through locn are the symbolic addresses of 
instructions to which control may be transferred. The second 
operand is an index variable. The address to which control is trans- 
ferred Is determined by the value of the index variable. 

The first address (locO) in the list of addresses which form the first 
operand is the address to which you want control transferred if the 
index variable exceeds the extents of list loci— locn. 

The next address in the list, loci, will get control if the index variable 
is equal to 1, loc2 if the Index variable is equal to 2, etc. 

Figure 8-4 illustrates the operation of a computed GOTO with an 
index variable outside the range of the list. The index variable is VAL1 
and is set to zero by the MOVE statement at location "START". 
Zero is outside the range of loci— locn (NDX1, NDX2 in this case), 
and the computed GOTO transfers control to the address at locO 
(ERROR). 
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PROGl 
START 



PROGRAM 
MOVE 



START 



VAL1,0 



GOTO 
DATA 




,(ERROR, NDX1,NDX2),VAL1 
F'O' 



PROGSTOP 

ENDPROG 

END 



Figure 8-4. Computed GOTO 



IF STATEMENT 



The same thing would happen if the index variable were greater 
than 2. In this example, the only valid values for the index variable 
are 1 or 2, which would result in a transfer of control to location 
NDX1 orNDX2. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference {SC34-1706), "IF", "ELSE", "ENDIF." 

The GOTO statement gives you the ability to transfer control to 
another part of a program; IF statements provide a means of deter- 
mining when a transfer or branch is required. 

The format for an IF statement is shown in Figure 8-5. 
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label 

OPTIONAL 



IF (relational statement) 



MUST BE CODED 
Figure 8-5. IF Format 



,GOTO,loc 

^^ , ' 

OPTIONAL 



The first operand is a relational statement, and ail IF statements must 
iiave at least one relational statement. A relational statement expresses 
a comparative relationship between two variables, or between a 
variable and an explicit value. An IF may be coded to include a GOTO 
(second operand) and a specified location (third operand). For 
instance, (Figure 8-6); 



TESTl IF (A, EQ,B), GOTO, STEPS 



Figure 8-6. IF/GOTO example 

This Statement may be interpreted as "Transfer control to location 
STEPS if the value in location A is equal to the value in location B." 
If A is not equal to B, execution will continue with the instruction 
following the I F. The "IF with GOTO" is the simplest form of I F 
that can be coded. I F statements may also take the form of 
structures, in which entire code sequences may be executed or 
sl<ipped, depending on whether the relationship expressed in 
the relational statement is true or not. The basic IF structure is 
illustrated in Figure 8-7. 



IF 



I 



ENDIF 



END OF "IF" 
STRUCTURE 




(A,EQ,B) 



"TRUE" CODE 

EXECUTED IF THE 
RELATIONSHIP 
EXPRESSED IN THE 
RELATIONAL ST ATE- 
ENT IS TRUE 



RELATIONAL 
STATEMENT 



RELATIONAL 
MNEMONIC 
CAN BE: 

EG EQUAL 

NE NOT EQUAL 

GT GREATER THAN 

LT LESS THAN 

GE GREATER OR EQUAL 

LE LESS OR EQUAL 



IF RELATIONSHIP EXPRESSED 
IN THE RELATIONAL STATEMENT 
IS NOT TRUE, "TRUE" CODE 
WITHIN "IF" STRUCTURE IS 
SKIPPED, AND EXECUTION 
CONTINUES WITH FIRST 
INSTRUCTION FOLLOWING 
"ENDIF" STATEMENT 



Figure 8-7. IF structure 
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All IF structures must end with an END IF statement, except when 
using GOTO. In the example, the code between the I F statement 
and the ENDIF will be executed if the relationship expressed in the 
statement is true (A is equal to B). If the relationship is not true, 
the true code will be bypassed, and execution will continue with the 
statement following the ENDIF. 

In Figure 8-8, one more statement is added to the IF structure. The 
ELSE statement starts the false code; these instructions will be 
executed if the relationship expressed in the statement is not true, 
bypassing the "true" code. True code begins following the IF in an 
IF structure, and ends with the ENDIF if no ELSE statement is coded 
(Figure 8-7), or ends with an ELSE statement if one is used (Figure 
8-8). 



NOT REQUIRED, BUT MAY BE 
CODED FOR DOCUMENTATION 



IF 



(A,EQ,B),THEN 



ELSE 



"TRUE 
CODE 



-h 



EXECUTED IF A=B 



"FALSE 
CODE 

ENDIF 

-« 



V 



EXECUTED IF A?^B 



EXECUTION CONTINUES HERE 
AFTER EITHER "TRUE" OR 
"FALSE" CODE WITHIN "IF" 
STRUCTURE HAS EXECUTED 



Relational Conjunctions 



Figure 8-8. IF/THEN/ELSE 

False code begins with an ELSE statement, and ends with the 
ENDIF, which defines the end of that IF structure. 



As you found in the reading assignment, IF structures can be very 
complex. Figure 8-9 is an example of a structure using logical con- 
junctions and nesting. A logical conjunction forms a logical link 
between two or more relational statements. A nested IF 
structure is one that appears within the true or false code of a 
previous IF structure. 
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LOGICAL CONJUNCTION OF 
RELATIONAL STATEMENTS 



IF (A,EQ,B),ANb,(C,EQ,D),THEN 

GOTO ALLEQUAL 

ELSE 

IF (A,EQ,B) 

MOVE CD 



ELSE 



MOVE A,B 



ENDIF 



NESTED "IF" 
STRUCTURE 



ENDIF 



Figure 8-9. Complex IF structure 



A transfer to ALLEQUAL will take place only if both 1) A=B and 
2) C=D. The false code is another IF structure, nested within the 
first, with its own true and false sections. Notice that each IF 
structure is ended with its own ENDIF statement. 



DO STATEMENT 



READING ASSIGNMENT: IBM Sereis/1 Event Driven Executive 
Language Reference (SC34-1706), "DO", "ENDDO." 

The DO instruction alters the sequence of program execution by 
causing repetitive execution of the same section of code. The DO 
statement establishes the start of a DO loop, and the end of the loop 
is defined by an ENDDO statement. The code that is repeatedly 
executed is the instruction or instructions that are coded between the 
DO and ENDDO statements. 

One form of the DO statement is illustrated in Figure 8-10. The 
count operand is an integer value, or the label of a storage location 
containing an integer value, indicating the number of times you want 
to execute the loop. 
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label 



DO 



count', TIMES, INDEX= 



OPTIONAL MUST BE CODED OPTIONAL 
Figure 8-10. 



TIMES has no function other than documentation, and does not 
have to be coded. The INDEX= keyword operand may be coded as 
the label of a word of storage. Before the DO loop is executed for 
the first time, the storage location is reset to zero. Then, before 
execution of the first instruction following the DO statement, and 
with every succeeding pass, 1 is added to the storage location. In the 
event that a branch out of the loop is done before the count has 
gone to zero, the location specified in the INDEX= operand can be 
checked to see how many executions occurred. 

Figure 8-1 1 is a flowchart representing the execution sequence of the 
DO count,TIMES form of DO loop. (If the INDEX= operand is 
not coded, the top two blocks would not apply.) 



DO COUNT 



SET INDEX 
LOCATION 
TO ZERO 



ADD+1 
TO INDEX 
LOCATION 



EXECUTE CODE 
BETWEEN "DO" 
AND "ENDDO" 



SUBTRACT 
1 FROM 
COUNT 




YES 



CONTINUE EXECUTION 
WITH INSTRUCTION 
FOLLOWING "ENDDO" 

Figure 8-11. "DO count" operation 
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Notice that a post-execution escape mechanism is used (trailing 
decision loop). The count is not checked for zero until the loop 
has completed the first execution. Therefore, if count is initially 
zero, one execution would still occur. 

There are two other forms of the DO statement, both employing 
relational statements. DO WHILE will repetitively execute the 
instructions within the loop while the relationship expressed remains 
true. DO UNTIL will keep on executing the loop until the relation- 
ship expressed in the relational statement becomes true. The 
format for these two instructions is illustrated in Figure 8-12. 



DO 



WHILE 
UNTIL* 



relational statement • 



label 

OPTIONAL MUST BE CODED 

Figure 8-12. WHILE/UNTIL format 



The relational statements are coded the same way as those used with 
the IF statement, and like the IF, two or more relational statements 
may be formed into a statement string, using the logical conjunctions 
AND and OR. 




DO UNTIL 



EXECUTE CODE 

BETWEEN "DO" 

AND"ENDDO" 
I 



CONTINUE EXECUTION 
WITH INSTRUCTION 
FOLLOWING "ENDDO" 
Figure 8-13. WHILE/UNTIL operation 



EXECUTE CODE 
BETWEEN "DO" 
AND "ENDDO" 




CONTINUE EXECUTION 
WITH INSTRUCTION 
FOLLOWING "ENDDO" 



Figure 8-13 illustrates the execution sequence of DO WHILE and 
DO UNTIL. DO WHILE has a pre-execution (leading decision loop) 
escape mechanism. The relational condition is checked before the 
first execution and, if not true, no execution takes place. DO UNTIL, 
like DO count, does not check until completing the first execution 
of the loop. Even if the relational condition is true, one execution 
will occur. 
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In combination, the GOTO, IF, and DO statements provide the 
application programmer with the tools necessary to make execution 
time decisions, and to alter program execution flow if required. 

Figure 8-14 is an example of all three statements used together. In the 
course of program execution, the variable Dl FF is set to zero Q . 
When the IF statement is executed Q , a transfer of control to loca- 
tion DONE will occur if variable A is equal to variable B. If the transfer 
to DONE takes place and DIFF (difference between A and B) is checked, 
the difference will be zero. 



MOVE 



DIFF,0- 





►IF 


(A,EQ,B),GOTO,DONE 




riF 


(A,GT,B),THEN 




DO 


UNTIL,(A,EQ,B) 




ADD 


DIFF,1 




ADD 


B,l 




ENDDO 






ELSE 






DO 


UNTIL, (A, EQ, 8) 




ADD 


DIFF,1 




ADD 


A,l 




ENDDO 
ENDIF-* 


B 



v.. 



DONE 



Figure 8-14. IF/GOTO/DO 

If A is not equal to B, execution continues with the IF structure Q • 
The true code of the IF is a nested DO loop Q which will repetitively 
execute, accumulating the difference between A and B in DIFF until 
the two variables are equal. This code will execute only if the variable 
A were greater than B when the IF statement was executed. 

If B were greater than A, the false code of the IF structure Q , 
another nested DO loop, would repeatedly execute, and again, the differ- 
ence between A and B is accumulated in DIFF. 

In all cases, when execution continues at location DONE, A will be 
equal to B, and DIFF will contain the absolute difference that existed 
between A and B at the outset. Notice that the I F structure must end 
with an ENDIF D . 
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PROGRAM SEQUENCING REVIEW EXERCISE - QUESTIONS 

Using the coding example below, answer the questions which follow. 



IFIST 
IF2ND 



ELSE2ND 



END2ND 
ELSEIST 

ENDIST 
COMPGO 



IF 


(A,NE,B) 


IF 


(A,GT,B),THEN 


SUB 


A,B 


MOVE 


VAL1,A 


ELSE 




SUB 


B,A 


MOVE 


VAL1,B 


ENDIF 




ELSE 




GOTO 


EXIT4 


ENDIF 




GOTO 


(ERR, EXIT1,EXIT2, EXITS), VALl 



1 . Assuming that A=5, and B=3, the next statement to be executed 
after execution of the code in the example is at location 

a. ERR 

b. EXIT1 

c. EXIT2 

d. EXIT3 

e. EXIT4 

2. Assuming that A=22, and B=23, the next statement to be exe- 
cuted after execution of the code in the example is at location 

a. ERR 

b. EXIT1 

c. EXIT2 

d. EXITS 

e. EXIT4 

3. Assuming A=0, and B=-5, the next statement to be executed 
after execution of the code in the example is at location 

a. ERR 

b. EXIT1 

c. EXIT2 

d. EXIT3 

e. EXIT4 
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4. The "true" code for the IF structure beginning at location I FIST 
consists of 

a. the code starting at IF2ND and ending at ELSE2ND 

b. the code starting at IF2ND and ending at END2ND 

c. the code starting at IF2ND and ending at END 1ST 

d. none of the above 

5. If control is transferred to location EXIT4, then the following is 
true; 

a. VAL1=4 

b. A is greater than B 

c. B is greater than A 

d. A and B are equal 

e. none of the above 

6. How many times will the DO loop below execute? 



DO 



17, TIMES, INDEX=TWO 



ENDDO 



Answer: 
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7. Using the coding example below, pick the correct statement from 
the list of statements which follow 



DOl DO UNTIL, (X,EQ,Y), OR, (Y,GT,X) 

D02 DO WHILE, (X,EQ,Y) 

DOS DO UNTIL, (X,NE,Y) 

ADD Y,l 

ENDD03 ENDDO 

ENDD02 ENDDO 

ENDDOl ENDDO 



Assume when execution begins, X=Y. 

a. All three DO loops will execute one time. 

b. The first two DO loops will execute once, but the innermost 
DO loop (DOS to ENDD03) will not be executed. 

c. None of the DO loops will execute, because X Is equal to Y 
when the first DO statement is encountered (DOl). 

d. Question is not valid, because DO loops cannot be nested. 
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PROGRAM SEQUENCING REVIEW EXERCISE - ANSWERS 



1. The correct answer is choice c. A is not equal to B, so the "true'"'^ 
code following the IF at location IF1ST will be executed. A is V_y 
greater than B, so the "true" code of the nested I F at I F2ND is 
executed. VAL1 is set to 2, the result of the SUBTRACT oper- 
ation. Execution continues at location COMPGO, skipping the 
"false" code of the nested IF and the first IF. VAL1, the index 
variable of the computed GOTO at location COMPGO was set to 

2 by the statements in the preceding IF structure, so control is 
transferred to location EXIT2. 

2. The correct answer is choice b. A is not equal to B, so the "true" 
code of IF1ST is executed. A is not greater than B, so the "false" 
code of the nested IF (ELSE2ND to END2ND) is executed, and 
the difference between A and B is placed in VAL1 (VAL1 = 1). 
The computed GOTO at COMPGO will transfer control to loca- 
tion EXIT1. 

3. The correct answer is choice a. Execution proceeds exactly 

as in the answer to question 2 above (A=?^B,A<B), but the difference 
between A and B is 5. When the computed GOTO at COMPGO 
is executed, the index variable, VAL1, contains a value which 
exceeds the range of the list, and therefore control is transferred 
to location ERR. 

4. Choice b is the correct answer. "True" code is everything between 
the I F and the E LSE statement/or the I F and the EN D I F if E LSE 
is not coded. 

5. Choice d is correct. If A and B are equal, the relational statemeri._ 
in the IF at location I FIST is false, and the "false" code is 
executed. The "false" code is the unconditional GOTO at loca- 
tion EXIT4. 

6. The DO loop will execute 17 times. The index variable, TWO, will 
be set to zero before the first execution of the DO loop, and 
assuming that the code within the DO loop does not contain any 
GOTO statements, the loop will execute 17 times, and the index 
variable TWO will contain 17 after the DO loop is exited. 

7. The correct answer is choice a. Although X and Y are equal at the 
time the first DO statement is executed (D01), the relational con- 
dition associated with a DO UNTIL statement is not checked until 
after the first execution of the DO loop. 

The second DO loop (002) starts with a DO WHILE statement. 
The DO WHILE checks for the relational condition before execut- 
ing for the first time, but since the condition is true, execution 
drops to the second nested DO loop at DOS. 
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The innermost DO loop is another DO UNTI L, this time with a 
"NOT EQUAL" relational mnemonic. The ADD operation 
within the loop makes the two variables, X and Y not equal, 
thereby satisfying the exit condition for D03, the innermost 
loop. 

The exit condition for the second loop, D02 (first nested loop) 
is also satisfied, because it is supposed to execute only as long as 
X is equal to Y, which is no longer true. 

The first loop will also exit, because although X is not equal to Y, 
which is the relational condition specified in the first part of the 
relational statement, Y is greater than X, which is specified in 
the second part of the relational statement, and the two parts 
are joined by the OR conjunction. All three loops will therefore 
exit after a single execution. 

Note: The relational statement used with the DO at location D01 
could have been coded as: 



DOl DO UNTIL, (Y,GE,X) 

and would have executed with the same effect as the form used in 
the example. 
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Section 9. Timers 



y GETTIME INSTRUCTION 



OBJECTIVES: After completing this topic, the student should be 
able to: 

1 . Use the G ETTI M E instruction to access the time-of-day and 
date from an application program 

2. Use the INTIME instruction to measure time intervals 

3. Cause user-defined delays in task execution by using the 
STIMER instruction along with the "WAIT on timer" 
capability 

If you have the hardware timer feature installed on your Series/1 
4955 Processor, or your processor is a 4952 (has self-contained timer), 
you can include support in your Event Driven Executive supervisor, 
which provides several time/timing functions that may be used by 
application programs. In addition to maintaining a time-of-day clock, 
the system also provides a time interval (elapsed time) clock, and has 
the capability to suspend task execution (go into wait state) for 
specified lengths of time. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "GETTIME." 

The time-of-day (TOD) clock is maintained in hours, minutes, and 
seconds. At initial program load (I PL), the clock is all zeros and begins 
running. It may be set to actual clock time using the $T operator 
command, and will maintain clock time from that point on. 

The GETTIME instruction is used to move the TOD values into a 
user program. The GETTIME format is; 

I I 

label j GETTIME loc!, DATE= 

OPTIONAL MUST BE CODED OPTIONAL 
Figure 9-1. GETTIME format 
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INTIME INSTRUCTION 



The hours, minutes, and seconds are maintained by the system in three 
storage words in the supervisor. The user must define a three word 
storage area in the application program issuing the GETTIME, into 
which the hours, minutes, and seconds can be moved. The ioc 
operand is coded as the label of the first position of the three word user- 
defined area. 

The $T operator command also allows you to enter the date in the form 
of month-day-year or day-month-year (depending on how the 
DATEFMT= keyword operand of the SYSTEM statement was coded 
during system generation). If the DATE= keyword operand is coded 
DATE=YES, the GETTIME instruction will transfer the date as well 
as the time into the application program. Three words are also required 
for the date, and these must be contiguous with and following the 
three word area defined to hold the time. 

Each of the six words in the TOD and date locations are direct binary 
equivalents of the information they represent. For instance, the third 
word of TOD information {loc+4) is seconds, and when it reaches 59, 
the next increment resets it to zero, and the minutes word is increased 
by 1 (loc+2). Hours is increased by 1 when 60 minutes have elapsed, 
days by 1 at midnight, etc. By using GETTIME, an application pro- 
gram can time stamp reports, transactions, or any system event In 
which Information as to the actual time of occurrence is useful. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive ( 
Language Reference (SC34-1706), "INTIME." 

Some applications need to measure elapsed time: how long it takes 
for a certain code sequence, task or program to execute, or how much 
time has passed between the occurrences of events. These time intervals 
may be very short, and therefore, cannot be accurately measured using 
TOD values, whose resolution Is only to the nearest second. 

In addition to the TOD clock, the system maintains a relative time 
clock. It consists of a double precision (two-word) integer, which is 
initialized to zero at system IPL. Every millisecond thereafter, this 
value is Incremented by 1, and at any given instant, therefore, con- 
tains the elapsed time In milliseconds since the system IPL. (A double- 
precision integer will contain a count of milliseconds comprising 
approximately 49 days elapsed time, before rolling over to zero and 
starting again.) 

The INTIME instruction is used to read the relative time clock 
value into a user program. The format for the INTIME statement 
is shown in Figure 9-2. 

label ilNTIME rel time, Ioc !, INDEX 

OPTIONAL MUST BE CODED OPTIONAL 

Figure 9-2. INTIME format 
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STIMER INSTRUCTION 



The reltime operand is coded as the label of a user-defined double- 
precision integer variable into which the relative tinne value will be 
moved. The loc operand Is coded as the label of a user-defined single 
precision integer, which will be set to the number of milliseconds 
that have passed since an INTIME instruction, referencing this reltime 
location, was executed in this program. (A single-precision integer will 
hold approximately 65 seconds elapsed time in milliseconds, before 
rolling over to zero and starting again.) 

The INDEX keyword, if coded, indicates that automatic indexing 
is to be used in conjunction with a BUFFER statement. If INDEX 
is coded, the loc operand must be the label of a BUFFER statement, 
instead of a single-word integer. When automatic indexing is used, 
repetitive executions of an INTIME instruction result In the storing 
of successive elapsed time values in successive buffer positions. The 
use of INTIME with automatic indexing is illustrated at the end of 
this section, along with the other timer instructions. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "STIMER." 

Every task has a software timer associated with it. This timer will 
time out after a user-specified number of milliseconds has elapsed 
(60 seconds or 60,000 milliseconds maximum). The desired time 
interval is set and the timer started by the STIMER instruction, 
whose format is illustrated In Figure 9-3. 

label I sTIMER count!, WAIT 
OPTIONAL MUST BE CODED OPTIONAL 
Figure 9-3. STIMER format 



The count operand is coded either as the number of milliseconds you 
want to elapse before the timer expires, or as the label of a word of 
storage containing the desired number of milliseconds. If the WAIT 
keyword is coded, the task will go into the wait state until the specified 
time interval has passed. Execution will resume with the instruction 
following the STIMER. 

The WAIT does not have to be coded as part of the STIMER Instruction, 
but may appear later as an explicit WAIT on the keyword operand 
TIMER. This acts in the same manner as a wait on an event, the event 
being expiration of the time delay. Using this method, the timer is 
started, and execution continues with the instruction following 
STIMER. When the WAIT on TIMER is encountered, the WAIT 
will fall through if the time interval has already passed, or the task 
will go into a wait state for the amount of time remaining. 
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TIMING FUNCTIONS -CODING EXAMPLE 



Figure 9-4 is a program tiiat exercises all of the timing functions 
previously discussed in this section. The first instruction in the pro- 
gram is GETTIME at location STARTIME. It will place the TOD 
values for hours, minutes, and seconds into the three words defined 
at location STARTED. 

The DO loop starting at DOSTART and ending at DOEND will 
execute three times. Each time, the INTIME instruction at location 
11 will place the time elapsed since IPL in the double precision 
integer at SINCEIPL, and will put the time that has elapsed since the 
last INTIME execution in the next successive buffer location of the 
buffer defined at TIMEBUF. Both values are in milliseconds. 

The STIMER instruction at location S1 causes a 5 second delay 
(5000 milliseconds = 5 seconds) in each execution of the DO loop. 
After the third delay, the DO loop exits, and the STIMER at location 
S2 executes. This starts a 10 second timer running but, since the 
WAIT operand is not coded, execution continues. 



TIMETEST 


PROGRAM 


STARTIME 


STARTIME 


GETTIME 


STARTED 


DOSTART 


DO 


3, TIMES 


11 


INTIME 


SINCEIPL, TIMEBUF, INDEX 


SI 


STIMER 


5000, WAIT 


DOEND 


ENDDO 




S2 


STIMER 


10000 


12 


INTIME 


SINCEIPL, LASTIME 


ENDWAIT 


WAIT 


TIMER 


G2 


GETTIME 
PROGSTOP 


STOPPED, DATE=YES 


STARTED 


DATA 


3F'0' 


SINCEIPL 


DATA 


2F'0' 


TIMEBUF 


BUFFER 


3 


LASTIME 


DATA 


F'O' 


STOPPED 


DATA 

ENDPROG 

END 


6F'0' 



Figure 9-4. Timing functions 

The INTIME instruction at 12 places the elapsed time since IPL 
into SINCEIPL again, and puts the elapsed time since a previous 
INTIME instruction referencing SINCEIPL was executed into the 
single precision integer at LASTIME (INDEX not coded). The WAIT 
at ENDWAIT puts the program in a wait state, until the expiration 
of the 10 second time delay that was started by the STIMER at S2. 
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When the 10 seconds are up, the GETTIME at G2 executes, and the 
program ends. This time DATE=YES is coded, so a six-word area 
is defined at location STOPPED. Hours, minutes, and seconds will 
be placed in the first three words, and month, day, and year in 
the next three. 

When using INTIME to time events where a few milliseconds 
difference is critical, keep in mind that the time values retrieved by 
your program represent the time that the INTIME instruction is 
executed. If the task issuing the INTIME is of a lower priority than 
other tasks active in the system at the same time, a delay In execution 
of the INTIME may result, and will be reflected in the clock value 
retrieved. 
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TIMERS REVIEW EXERCISE - QUESTIONS 



All of the questions in this Review Exercise refer to the program in 
Figure 9-4. For simplicity, assume that no time is used to execute 
instructions, no other tasks are running in the system, and system 
overhead is zero. 

At the time that the program begins execution, the date has been set 
at January 1st, 1979, and it is exactly 5 p.m. (1700 hours). The system 
IPL was at exactly 4 p.m. 

1. What will be in the three words beginning at location STARTED 
after execution of theGETTIME at location STARTIME? 

Answer: STARTED 

STARTED+2 

STARTED+4 



What will be the values in the double precision integer at 
SINCEIPL and the buffer at TIMEBUF after the first 
execution of the INTIME instruction at 11? 

Answer: SINCEIPL 

TIMEBUF 

TIMEBUF+2 

TIMEBUF+4 

After the second execution? 



Answer: SINCEIPL 
TIMEBUF 
TIMEBUF+2, 
TIMEBUF+4 

After the third execution? 

Answer: SINCEIPL 
TIMEBUF 
TIMEBUF+2 
TIMEBUF+4 



5. What will be in SINCEIPL and in LASTIME after execution 
of the INTIME instruction at location 12? 

Answer: SINCEIPI 

LASTIME 



What will be in the six words beginning at location STOPPED 
after execution of the GETTIME at location G2? 

Answer: STOPPED 

STOPPED+2 



STOPPED+4 
STOPPED+6 
STOPPED+8 
STOPPED+10 
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TIMERS REVIEW EXERCISE - ANSWERS 

1. STARTED _\7_ 

STARTED+2 _0_ 
STARTED+4 



The TOD clock is kept using military time, on a 24 hour-a-day 
basis. Five p.m. is therefore 17 hours, minutes, and seconds. 

SINCEIPL 3,600,000 

TIMEBUF _0 

TIMEBUF+2 _0 

TIMEBUF+4 



If the system I PL was at 4 o'clock, and it is now 5 o'clock, the 
relative time clock has been running for one hour, or 3,600,000 
milliseconds. (1 hr x 60 minutes x 60 seconds x 100 milliseconds/ 
second). The first word in TIMEBUF is zero, because the elapsed 
time from the last time an INTIME instruction referencing 
SINCEIPL was executed is zero; this is the first time the 
INTIME has executed. 

SINCEIPL 3,605,000 

TIMEBUF 



TIMEBUF+2 5,000 
TIMEBUF+4 



The second time through, the 5 second delay at SI has occurred. 
Total elapsed time since I PL has increased by 5,000 milliseconds 
(SINCEIPL), and the time elapsed since the first INTIME execution, f^ 

also 5000 milliseconds, is automatically indexed into TIMEBUF+2. V 

SINCEIPL 3,610,000 

TIMEBUF _0 

TIMEBUF+2 5,000 
TIMEBUF+4 5,000 



A second 5 second delay has occurred, increasing SINCEIPL 
by another 5000 milliseconds, and placing 5000 milliseconds 
in the third buffer position, TIMEBUF+4. 

5. SINCEIPL 3,615,000 



LASTIME 5,000 



Before exiting the DO loop, an additional 5 second delay occurred, 
adding another 5000 milliseconds to SINCEIPL. Because the 
INTIME instruction references the same "reltime" operand as the 
last INTIME execution (SINCEIPL), LASTIME is set to 5000 
milliseconds. If the INTIME at 12 had a different "reltime" 
operand, it would be treated as a first execution, and LASTIME 
would indicate zero elapsed time. 
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6. 



STOPPED 


17 


5 p.m. 


STOPPED+2 





minutes 


STOPPED+4 
STOPPED+6 


25 
1 


25 seconds 
January 


STOPPED+8 


1 


1st 


STOPPED+10 


79 


1979 



Fifteen seconds in tiie DO loop, plus the 10 second delay at 
S2 have elapsed. 
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Section 10. Disk/Diskette I/O 



OBJECTIVES: Upon successful completion of this topic the student 
should be able to: 

1. Understand the logical layout of disk, diskette and tape 

2. Define data sets in a PROG RAM statement 

3. Read records using the READ statement 

4. Write records using the WRITE statement 

5. Use NOTE and POINT to access and set the next record 
indicator 

6. Pass data set definitions to programs loaded from a terminal 
or from another program 

7. Pass data set definitions to an overlay program from the program 
loading the overlay 



DEVICES SUPPORTED - DISKETTE 

-^ The Event Driven Executive supports both the 4964 Diskette Storage 

Unit, and the 4966 Diskette Magazine Unit. Diskettes used with the 
Event Driven Executive can be Diskette 1 (single-sided). Diskette 2 
(double-sided) or Diskette 2D (double-sided double-density) diskettes. 
EDX supports all diskettes formatted 256 bytes/sector and Diskettes 1 
and 2 formatted 128 bytes/sector. Diskette 2D can only be used in the 
4966 Diskette Magazine Unit. 



DEVICES SUPPORTED - DISK 



The 4962 Disk Storage Unit and the 4963 Disk Subsystem are non- 
removable direct access storage devices, available in several capacities, 
with or without fixed-head capability. All models of both devices are 
supported by the Event Driven Executive. 

For information on the physical layout of any of the disk/diskette 
storage devices, see the appropriate General Information manual for 
that device. 



DEVICES SUPPORTED - TAPE 



The Event Driven Executive supports all models of the 4969 Magnetic 
Tape Subsystem utilizing 800 or 1600 bpi magnetic tape. 
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Disk Volume Definition 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "Disk I/O." IBM Series/1 Event 
Driven Executive System Guide (SC34-1702), "Direct Access Storage 
Devices" and "DISK Configuration Statement." 

Event Driven Executive direct access storage has an hierarchical 
structure. The largest logical unit in the hierarchy is the volume. A 
volume is named contiguous area on disk/diskette, starting and 
ending on a cylinder boundary. 

Disk devices are identified to the supervisor by the DISK system con- 
figuration statement at system generation time. The DISK statement 
defines the type of disk and hardware address of disks to be supported 
by the supervisor. 

Volumes on disk are defined by the $INITDSK utility. Before allocat- 
ing any volumes, a user must initialize the disk device. This device 
initialization creates a volume directory which will contain control 
information about volumes that are subsequently allocated on the 
device. Once the volume directory is created, volumes can then be 
allocated. Before using a newly created volume, it must be initialized; 
that is, a directory must be created to contain the control information 
about data sets that will subsequentially be allocated in the volume. 



L 
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Diskette Volume Definition 



Tape Volume Definition 



Data Sets 



Logical volumes defined on disk devices exist on a non-removable 
storage medium. The names used to symbolically reference these 
disk volumes (EDX002, ASMLIB, etc.) are recorded in the volume 
directory of the device. Diskettes, being removable, also have the 
volume name written on them. 

A DISK statement is used to define a diskette device (4964 or 4966), 
and to establish the device hardware address. This generates the 
physical device tables the supervisor requires to operate the device. 

A logical volume on diskette encompasses the entire diskette. A 
diskette volume mounted on a 4964 device is considered to be a logical 
volume, as only a single diskette may be mounted and online at a time. 
With the 4966 Diskette Magazine Unit, up to twenty-three volumes 
may be online. 

Diskette volumes are created (volume name written, directory created, 
etc.) by the $INITDSK utility. As many volumes as required may be 
created. 



Each magnetic tape is a volume which is allocated by the $TAPEUT1 
utility. Only one volume is defined for each physical tape drive known 
to the system. The actual volume label is determined by the system 
when the tape is placed on line ($VARYON). 



Data sets are members of a library. A data set is a named contiguous 
space whose length is determined by the user when the data set is 
created. Disk or diskette data sets are allocated by the user, using 
utility program $DISKUT1, or, in some cases, automatically allocated 
by certain special purpose system utilities. Data sets may be defined 
with program organization or data organization, depending on what is 
to be stored. Program organization is used for data sets that will 
contain executable (loadable) Event Driven Executive programs. Data 
organization is used for work files ($EDIT1N, $FSEDIT, $LINK, 
$EDXASM, SSIASM work files), user source modules and application 
data sets. 

Tape data sets are allocated by the user using the $TAPEUT1 utility. 
Data sets can only be defined as data organization. Programs cannot 
be loaded and executed from tape. 
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Records 



Record/Sector Relationship 



When a data set is allocated, an entry is made in the directory of the 
logical volume in which the data set is defined. The directory entry will 
contain such information as the data set name, organization (program 
or data), location of the data set starting point within the volume, and 
the length of the data set, in records. 

A record is 256 bytes in length, and is the smallest logical unit in the 
Event Driven Executive direct access storage hierarchy. A record is the 
basic unit that is accessed from user and system programs. Data sets 
are named, contiguous groups of 256-byte records. 



Diskettes used as Event Driven Executive logical volumes can be for- 
matted in 128-byte or 256-byte sectors. When formatted in 128-byte 
sectors, two diskette sectors constitute a single 256-byte logical record. 
On a 4962 disk, physical sectors and logical records are the same length, 
256 bytes. The physical sector size on 4963 disks is 512 bytes, 
allowing two logical 256 byte records in each physical sector. 

In all cases, user access to direct access storage is at the logical 256-byte 
record level. System routines compensate for physical sector/logical 
record mismatches, making the hardware differences between devices 
transparent to the user. 

Figure 10-1 summarizes the direct access storage logical layout. 



PROGRAM STATEMENT DS= OPERAND 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "PROGRAM Statement." 

Data sets accessed from user programs must be preal located on disk or 
diskette ($DISKUT1 utility), and must be named in the DS= keyword 
operand of the using program's PROGRAM statement. Figure 10-2 
shows how the DS= operand is coded for data sets residing on the I PL 
or other logical volumes. 
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VOLUME 
CREATED BY 
SINITDSK 

4964/4966 



4962/4963 



CONTAINS CONTROL 
INFORMATION ABOUT 
VOLUMES ON DISK \ 




DATA SET CONTAINS 
RECORDS, EACH 
256 BYTES 



TWO 128-BYTEOR 
ONE 256-BYTE 
SECTOR(S) ON 
DISKETTE DEPEND- 
ING ON HOW 
FORMATTED 



Figure 10-1. Disk/diskette logical layout 



V2 SECTOR 
ON 4963 
(TRANSPARENT 
TO USER) 
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"FILEA" IS ONLY DATA SET 
USED, AND IS ON THE IPL 
VOLUME - NO PARENTHESES 
REQUIRED, NO VOLUME RE- 
QUIRED (DEFAULTS TO IPL) 



DSEXAMPl PROGRAM GO,DS=FILEA 



MULTIPLE DATA SETS, ALL 
ON IPL VOLUME-ENCLOSE 
LIST IN PARENTHESES, VOLUME 
DEFAULTS TO IPL 



DSEXAMP2 PROGRAM GO,DS= 



"7 V 

(FILEA, FILEB) 



"FILEA" AND "FILEB" HAVE NO 
VOLUME SPECIFIED-DEFAULT 
TO IPL VOLUME 



"FILEX"ON DIFFERENT 
VOLUME-VOLUME MUST 
BE SPECIFIED 



DSEXAMP3 PROGRAM GO, DS=((FI LEA) , (FILEB) , (FI LEX, EDX003) ) 



EACH ENTRY ENCLOSED 
IN PARENTHESES 




ENTIRE LIST 
ENCLOSED IN 
ADDITIONAL 
PARENTHESES 



Figure 10-2. DS= operand 

The IPL volume is the volume where the currently loaded (IPL) 
supervisor resides. The system will assume that data sets specified 
in the DS= operand list also reside on the IPL volume, unless a different 
volume is explicitly coded. Up to nine data sets may be coded in a 
DS= operand list. 

At the time a program is loaded, the loader ($LOADER) looks up all 
the data sets named in the PROGRAM statement's DS= operand list, 
and logically opens them for use by the program. If a named data set 
does not exist (was never allocated by $DISKUT1), resides on a volume 
other than that specified in the DS= operand entry, or is program 
rather than data organization, the load operation is terminated and an 
error message results. 



READ/WRITE STATEMENTS - DISK/DISKETTE 

READING ASSIGNMENT: IBM Series/1 Event Driven Executive 



Language Reference (SC34-1706), "READ", "WRITE, 
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The 256-byte records in data sets are transferred from disk /diskette 

to storage or storage to disk/diskette by READ and WRITE instructions. 

The format for READ and WRITE statements is Illustrated in Figure 10-3. 

DSx is the operand specifying which data set to use. The x in DSx is 
coded as an integer value between 1 and 9, and is a positional reference 
to one of the 9 possible data sets named in the DS= list of the PROGRAM 
statement. 



label 



OPTIONAL 



READ 
WRITE 



DSx,loc 



,count,relrecno,END=,ERROR=,WAIT=,PREC= 



OPTIONAL 



MUST BE CODED 
Figure 10-3. READ/WRITE format-disk/diskette 



DS1 would refer to the first data set in the list, DS2 to the second, 
continuing through DS9, referencing the ninth data set defined. 

The loc operand is coded as the label of the first byte of the (one or 
more contiguous) 256 byte storage area(s), into or from which the 
disk/diskette record(s) will be read/written. 



; 



label 

OPTIONAL 



READ pn 1^ 
WRITE ^^^>^o^ 



, count, relrecno, END-, ERROR=,WAIT=, PREC- 



OPTIONAL 



MUST BE CODED 
Figure 10-4. READ/WRITE count operand 



The optional count operand is coded as an integer value (or as the 
label of a program location containing an integer value) indicating 
the number of 256-byte records to be read or written. The user 
must ensure that adequate storage is reserved (beginning at location loc) 
to accommodate the number of records specified in count. If count 
is not coded, the system will default the count operand to 1, indicating 
that a single record will be read or written. If count is set to 0, the 
READ or WRITE will not be performed (execute as a no-op), and 
execution will continue with the next sequential instruction following 
the READ/WRITE. 



label 



OPTIONAL 



WRITE L>5X,ioc 



, count, relrecno,END==,ERROR==, WAIT-, PREC== 



OPTIONAL 



MUST BE CODED 
Figure 10-5. READ/WRITE relrecno operand 
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label 

OPTIONAL 



The relrecno operand is the relative record number (relative to the 
origin of the data set) to be read or written. It is coded as an integer, 
or as the label of a location containing an integer, which is the 
relative record number you want to access. The relrecno operand 
will default to 1 (indicating the first record in the data set) if it is 
left uncoded. 

For each data set used by a program (DS1, DS2, etc.), the system 
maintains a next-record pointer. This pointer is an indicator of the 
next sequential record in the data set and, at the time a program is 
loaded (before disk/diskette I/O has been performed), has an initial 
value of 1. It is updated by +1 after each READ or WRITE in which; 

a. relrecno is not coded 

b. relrecno is coded as 

c. the location specified by the label in relrecno is equal to 

Successive executions of READ/WRITE instructions in which 
relrecno has a value of or is not coded will therefore result in 
sequential access of the data set; i.e., the relative record number of 
the next record read/written will automatically be 1 greater than the 
last record read/written. A READ or WRITE with relrecno coded 
as an integer greater than 0, or with the contents of the location 
specified by the label in relrecno greater than does not disturb 
(increment) the next-record pointer. 



WRITE DSx,1oci, count, relrecno, END=,ERROR=,VIAIT-,PREC=^ 



OPTIONAL 



MUST BE CODED 
Figure 10-6. READ/WRITE END= operand 



The END= keyword operand is coded with the label of the instruction 
that you wish control transferred to when an attempt to READ or 
WRITE a record outside the physical boundaries of the data set is 
detected. This condition may occur because of a normal end-of-data 
set condition (attempting to READ or WRITE the next sequential 
record in a data set, when the last record read or written was the last 
physical record in the data set), or may be caused by a program logic 
error (for example, a READ or WRITE with relrecno erroneously 
set to a negative value). 

Note: A "logical-end-of-data" facility for READ operations is provided 
by a system subroutine called SETEOD. This subroutine will allow a 
user to set a given record number in a data set as the last logical record 
in that file. An attempt to read a record beyond the last logical record 
(although still within the physical boundaries of the data set) would 
result in a transfer to the label coded in the READ statement's END= 
keyword operand. 
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SETEOD is supplied as a system COPYCODE source module, and may 
be copied into user programs using the COPY assembler instruction. 



label 



^^^^ DSx loc 
WRITE L»^^»ioc 



OPTIONAL-^ 



, count ,rel recno ,END= ,ERROR= ,WAIT=: ,PR£C==; 



OPTIONAL 



MUST BE CODED 
Figure 10-7. READ/WRITE ERROR= operand 

The ERROR= keyword operand is coded with the label of the instruction 
that you wish to get control if an error is detected while executing a 
disk/diskette READ or WRITE operation. If END= is not coded and 
ERROR is coded^ an end-of-data set condition will result in a transfer 
to the ERROR= location. If END= is coded and ERROR= is not, all 
abnormal conditions other than end-of-data set will result in contin- 
uation of execution with the next sequential instruction following the 
READ or WRITE. If neither is coded, execution continues with the 
next sequential instruction in all cases. 

After each disk/diskette READ or WRITE operation, a completion 
code is returned to the user program (see Reading Assignment for a 
description of completion codes). The completion code is placed in 
the task code word (taskname) of the task issuing the READ or WRITE, 
and is also placed in a system control block that may be referenced 
by the symbolic positional data set name (DS1, DS2, etc.). This 
completion code can be accessed and analyzed by the user program 
to determine if the operation was successful and, if not, why it failed. 



label 



READ f^c; , 
WRITE "^x»'OC 



OPTIONAL^ 



, count, relrecno,END=. ERRORS, WAIT=,PREC~; 



OPTIONAL 



MUST BE CODED 
Figure 10-8. READ/WRITE WAIT= operand 



While a disk/diskette I/O operation is executing, there is an implied 
wait for the issuing task. Task execution is suspended (the task is 
placed in a wait state) until the I/O is complete. If the WAIT= 
operand is coded as WAIT=NO, the wait does not occur; while the 
I/O operation is in progress, task execution proceeds with the next 
sequential instruction following the READ or WRITE, overlapping 
I/O with processing. Also, if WAIT=NO is coded, the END= and 
ERROR= keyword operands are not allowed. Checking for errors 
is entirely a user responsibility (completion code in taskname or DSx), 
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In addition, the user must issue an explicit WAIT instruction, waiting 
on the completion of I/O event. This is a predefined system event, and 
the associated ECB is referenced (in the operand of the WAIT statement) 
by the symbolic positional data set name (DS1, DS2, etc) for the data 
set used. When the waited on ECB Is posted complete, the I/O operation 
has finished, and the completion code is available for inspection. 



label 



READ 
WRITE 



DSxJoc 



OPTIONAL^ 



,count,re1recno,EN0=', ERRORS, WAIT==,PREC=^ 



OPTIONAL 



MUST BE CODED 
Figure 10-9. READ/WRITE PREC= operand 

The PREC= keyword operand further defines the relrecno operand. If 
PREC= S (single precision) the relative record number is limited to a 
value of 32767. If PREC= D (double precision) is specified relative 
record numbers up to 2^'— 1 can be specified. If no PREC= operand is 
specified the default assumed is S (single precision). 



READ/WRITE STATEMENTS - TAPE 



Records in data sets are transferred from magnetic tape to storage or 
storage to magnetic tape by READ and WRITE instructions. As with 
disk/diskette, the DSx operand specifies the data set to be used. The 
format of the READ and WRITE statements Is shown in Figure 10-10. 



label 



READ p,<, . ^ 
WRITE Li:5X,ioc 



OPTIONAL'^ 



, count, blksize,END=,ERROR=,WAIT= 



OPTIONAL 



MUST BE CODED 
Figure 10-10. READ/WRITE format-tape 

All the operands as discussed previously for disk/diskette apply to tape 
READ/WRITE operations. Tape records can be variable In length and 
are normally read sequentially; therefore, a biksize operand is used 
instead of the relrecno operand. BLKSIZE indicates the number of 
bytes to be read from or written to tape. If no BLKSIZE is specified, 
it will default to 256. Since the maximum size of a tape record is 
32767 bytes, the PREC= operand does not apply. 
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NOTE/POINT STATEMENTS 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "NOTE", "POINT." 

The system-maintained next record pointer changes value (increments) 
each time a READ or WRITE (without a user-specified relrecno 
greater than 0) is executed. Using the NOTE instruction, a user 
program can find out the current value of the next record pointer. 
The next record pointer may be set to a user-specified new value 
using the POINT instruction. 



label 



NOTE DOy "loc pppp^ 

POINT '^^^'relrecno'^^''^ 



optional'' • ' 

must be coded 

Figure 10-11. NOTE/POINT format 

In Figure 10-11, the DSx operand is the symbolic positional reference 
to the data set whose associated next record pointer is to be retrieved 
(NOTE) or set (POINT). The second operand is coded as the label 
of a storage location that the NOTE instruction will move the 
current value of the next record pointer into, or that contains the 
new value which the POINT instruction will use to set the next 
record pointer. (When using the POINT instruction, the second 
operand may be coded as an integer value rather than the label of a 
storage location.) 



DISK/DISKETTE I/O CODING EXAMPLES 



The programs depicted in the next four figures (Figure 10-12 through 
10-15) are not meant to be practical examples of how to code disk/ 
diskette I/O operations in a user program. They are intended only to 
illustrate some of the concepts already discussed. 

In Figure 10-12, the READ instruction at location GO will execute 
as a no-operation. Execution will continue with the instruction 
following the READ, and no I/O is performed. The count operand 
is coded as storage location CTR. When the program is first loaded, 
location CTR contains zero, and a zero count indicates no records 
are to be read (or written, for a WRITE instruction). 



'•N,^ 
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DISKPGM PROGRAM GO,DS=WORKFILE 

GO READ DS1,BUFF,CTR,END=END0UT,ERR0R=E1 



Rl 



READ 



DS1,BUFF,END=END0UT,ERR0R=E1 



SET7 

R2 

ENDOUT 

El 

BUFF 
CTR 



POINT 

MOVE 

READ 

PROGSTOP 

\END~dF-DATA SET 
! ROUTINE 



DS1,7 
CTR 3 
DSl! BUFF, CTR, END=END0UT,ERR0R=E1 



\§BAQdlloufTNE\ 



BUFFER 
DATA 
ENDPROG 
END 



768, BYTES 
F'O' 



Figure 10-12. Count operand use 

The READ at location Rl has no count operand coded, so count 
defaults to 1, Indicating a single record will be read. Since reirecno 
is not coded, the relative record number defaults to the current value 
of the next record pointer. The next record pointer has not yet been 
altered, and is therefore at its initial value of 1, indicating the first 
relative record in the data set. The READ at Rl will read the first 
record in WORKFI LE into the first 256 bytes of the 768 byte area 
BUFF. After the I/O operation, the next record pointer is incre- 
mented to 2 (automatic system function). 

The POINT instruction at location SET? changes the next record 
pointer to point to the seventh relative record In the data set. The 
MOVE which follows sets location CTR to a value of 3. When the 
READ at R2 is executed, three 256 byte records (count = CTR = 3), 
beginning with relative record number 7 (reirecno defaults to next 
record pointer which was set to 7) will be read into storage, beginning 
at location BUFF. After the operation, the next record pointer will 
have a value of 10. 

In Figure 10-13, all count operands are left uncoded, so all READ 
operations will be single record reads (default count =1). In the first 
READ (location GO), reirecno is coded as location RECNBR, which 
has an Initial value of 2. The second relative record in WORKFI LE 
will be read into BUFF. The ADD Instruction following the READ 
updates the user-maintained relative record number in RECNBR by 
adding 3. When the READ at R2 Is executed, relative record number 
5 will be read into BUFF. 

The MOVE operation preceding the READ at R3 sets the reirecno 
location RECNBR to zero. A zero reirecno value causes a default 
to the next record pointer maintained by the system. 
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DISKPGM PROGRAM GO,DS=WORKFILE 

GO READ DS1,BUFF,,RECNBR,ERR0R=ERR0UTN,END=0UT 
ADD RECNBR,3 



R2 READ DS1,BUFF,,RECNBR,ERR0R=ERR0UTN,END=0UT 



MOVE RECNBR,0 
R3 READ DS1,BUFF,,RECNBR,ERR0R=ERR0UTN,END=0UT 



R4 READ DS1,BUFF,ERR0R=ERR0UTN,END=0UT 



PI PRO?_sjof 

OUT rEND-OFl)~AfASEf\ 
\ FtOUJlNE J 



ERROUTN [errOR'rOUT/NE] 



BUFF 


BUFFER 


256, BYTES 


RECNBR 


DATA 

ENDPROG 

END 


F'2' 



Figure 10-13. "relrecno" operand use 

The two previous READ operations (at GO and R2) both used a user- 
defined relrecno value greater than zero, so the next record pointer was 
not affected, and is still at its initial value of 1. The READ at R3 
will therefore read the first relative record in WORKFILE, because 
the MOVE operation preceding sets RECNBR to zero. 

The READ at R4 has no relrecno coded, and will also default to 
the next record pointer for a relative record number. This READ 
will read relative record number 2, since the next record pointer 
was incremented by 1 after the preceding READ at R3. 

In Figure 10-14, all count and relrecno operands are left uncoded, so 
all READ commands will read a single record, and the next record 
pointer will be used for the relative record number. 

The READ statement at GO has both END= and ERROR= operands 
coded. An end-of-data set condition will cause a transfer to location 
ENDR, and an error condition will result in execution of the instructions 
beginning at ERTN. If the operation is successful, relative record 
number 1 will be read into BUFF. 
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In the READ statement at R2, only the END= operand is used. Error 
checking is therefore a user responsibility, and is performed in this 
example by the IF statement immediately following the READ. The 
symbolic positional data set name, DS1, is checked for a completion 
code of -1. A -1 indicates a successful or normal operation. If the 
completion code is other than- 1, control is transferred to the error 
routine at ERTN. If the operation was successful, relative record 
number 2 would be read. 



DISKPGM PROGRAM GO,DS=WORKFILE 

GO READ DS1,BUFF,END=ENDR,ERR0R=ERTN 



R2 



READ DS1,BUFF,END=ENDR 

IF (DS1,NE,-1), GOTO, ERTN 



R3 



READ 



DS1,BUFF,ERR0R=E0 



R4 



READ DS1,BUFF 

IF (DS1,NE,-1),G0T0,E0 



DONE 
ENDR 



PROGSTOP 



\PRINTOUT"END j 



EO 
ERTN 



GOTO DONE 

IF (DS1,EQ, 10), GOTO, ENDR 



\PRINT OUT "DISK \ 
\ERROR"MSG \ 



BUFF 



GOTO 


DONE 


BUFFER 


256, BYTES 


ENDPROG 




END 





Figure 10-14. END= and ERROR= use 
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The ERROR= operand is coded in the READ statement at R3, but the 
END= is not. An end-of-data set condition will therefore be considered 
an error, and will cause a transfer to the label coded in the ERROR= 
operand, location EO. When END= is not coded, but you do not wish 
to treat end-of-data set as an error, the specific condition code that 
indicates end-of-data set must be checked for in the error routine. The 
IF statement at location EO checks for a completion code of 10, which 
is the completion code signifying an end-of-data set (relative record 
number outside range of data set) condition. If the code is 10, control 
transfers to the end-of-data set routine at ENDR, rather than 
continuing execution of ERTN. Relative record number 3 is read 
if normal operation occurs. 

The READ at R4 has neither END= nor ERROR= coded. Operation 
is the same as the previous READ at R3, except that the user must check 
for abnormal completion; there is no automatic transfer to an error 
routine, as is provided by the ERROR= operand. The completion 
code is checked by the IF statement following the READ, and transfers 
to EO (as did the ERROR=E0 in the READ at R3) if other than normal 
completion is detected. Normal completion results in a read of relative 
record number 4. 

Figure 10-15 illustrates the use of the WAIT= operand. The READ 
at location START is the same as the READ statements you are 
already familiar with. It will read a single record (count defaults to 1), 
the first relative record in data set WORKFILE (relrecno defaults to 
next record pointer = initial value of 1), into BUF1. If an error occurs, 
the ERROR= operand will transfer control to El, the start of the 
error routine. (END= is not required because, by definition, if 
WORKFILE exists, it has at least one record in it. Since this is a 
read of the first record in WORKFILE, end-of-data set will not occur.) 

While the READ at START is in progress, task DISKPGM is in a 
wait state (WAIT= operand not coded - default is WAIT=YES). 
After successful completion of the READ, the MOVE at location 
SETUP is executed, moving the 256 byte record in BUF1 into 
WRKAREA (128 words = 256 bytes). 

Now a second READ is issued (location R2), with the WAIT= operand 
coded as WAIT=NO. Since the READ at START used the next record 
pointer for a relative record number, it now has a value of 2. The 
READ at R2 will therefore read relative record number 2 into BUF1, 
updating the next record pointer to 3 upon successful completion. 

While the READ operation at R2 is in progress, execution of task 
DISKPGM continues, because the WAIT=NO operand prevents 
the implied wait for I/O completion from taking effect. While the 
next sequential record (relative record 2) is being read into BUF1, 
the program is operating on the data in the previous record, which is 
now in WRKAREA. Program execution is overlapping with the I/O. 
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DISKPGM PROGRAM 

BUFl BUFFER 

WRKAREA DATA 

START READ 

SETUP MOVE 

R2 READ 



START, DS=WORKFILE 

256, BYTES 

128F'0' 

DSl, BUFFI, ERROR^El 

WRKAREA, BUFFI, 128 

DSl, BUFFI, WAIT=NO 



! PROCESS THE DA TA IN \ 



I. 



'WORK AREA' 



Wl 


WAIT 


DSl 


IFl 


IF 


(DSl, EQ,-1), GOTO, SETUP 


IF2 


IF 


(DSl, EQ, 10), GOTO, OUT 



El 



PRINT DISK ERROR 
MESSAGE 



STOP _ _PROGSTOP 
OUT \ppii\i T END 'of 15 A TA 
\ SET MESSAGE 



GOTO 

ENDPROG 

END 

Figure 10-15. WAIT=NO 



STOP 



When WAIT=NO is coded, as illustrated in the READ at R2, the 
ERROR=and END= operands cannot be used. Error checking is 
therefore entirely a user responsibility. The I/O operation com- 
pletion code is not available until the I/O operation is finished. To 
find out when the I/O is complete and the completion code is avail- 
able, and also to resynchronize processing with I/O, the user must 
issue a WAIT on the completion of I/O event. 

The WAIT at location Wl uses the symbolic positional data set name 
DSl as the event name. The ECB is not coded, because it already 
exists in the TCB established by the PROGRAM statement. When the 
READ operation at R2 completes, the completion code is posted in 
location DSl. DSl is the symbolic address of the first word of the 
associated ECB, and therefore the completion of I/O event is marked 
as having occurred. 
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TAPE I/O EXAMPLES 



After the WAIT, execution continues with the IF statement at 
location IF1. If the I/O completed normally (condition code = -1), 
control is transferred to SETUP, which moves the new record into the 
work area. The READ at R2 starts the read of the next sequential 
record into BUF1, and the entire process continues to repeat until 
all records have been processed (end-of-data set) or an error occurs. 

If other than a normal completion is detected at I F 1 , the I F at I F2 
executes. An end-of-data set condition (completion code = 10) will 
cause a transfer to location OUT, the end-of-data set routine. Any 
other completion code is an error, and execution will continue with 
the error routine El, immediately following the IF. 



For comprehensive sample programs of magnetic tape operations, 
review the examples in the "Tape Management" section of the System 
Guide (SC34-1 702). 



LOAD-TIME DATA SET DEFINITION 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "LOAD", "PROGRAM." 

In all of the disk/diskette I/O examples thus far, data sets to be used 
by a program are named in the DS= list of the PROGRAM statement. 
This is adequate for very stable applications, where the program 
always uses the same data sets, and the names of those data sets are 
known at the time the program Is written. 

A stable situation is not always possible. At the time a particular 
program is being coded, data set naming conventions may not yet 
have been established, and data set names therefore would not be 
known. Also, the program could be a generalized file routine, de- 
signed to perform certain updating or maintenance functions on any 
of several similar data sets, a different data set (and data set name) 
each time the program is executed. 

By coding ?? in place of a data set name (in the DS= list of the 
PROGRAM statement), data set names can be specified at the time 
a program Is loaded for execution, rather than when it is coded. In 
Figure 10-16, the first entry in the DS= list is coded as ??, and the 
second entry as the data set name Fl LEA. 
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PROGA 


PROGRAM 


ASTART 


READ 


RD2 


READ 



ASTART, DS=(??,FILEA) 

DS1,BUF1,END=E1,ERR0R=E2 

DS2,BUF2,END=E1,ERR0R=E2 



PROGSTOP 






ENDPROG 
END 



Figure 10-16. Terminal load — data set passing 

Assuming this program is stored on disk/diskette under the name 
PROGA (same as initial task name), a terminal operator would re- 
quest that the program be loaded by hitting the ATTENTION key, 
and entering "$L PROGA". The system loader, recognizing that the 
first entry in the requested program's DS= list specifies a file to be 
defined at load time, will query the terminal operator with the 
prompt DS1=(NAME, VOLUME):. The operator would then respond 
with the name of the data set to be used as DS1 in the format 
NAME, VOLUME, if the data set resides on other than the IPL volume, 
or with just NAME if the data set is IPL volume resident. For example, 
if the operator enters FILEX in response to the prompt (FILEX is 
on the IPL volume), PROGA, when loaded, will execute as though 
the DS= list in the PROGRAM statement were coded DS=( FILEX, 
FILEA). The READ at location ASTART will read from FILEX, 
and the READ at RD2 from Fl LEA. 

Load time file definition is also possible when programs are loaded by 
other programs, rather than from a terminal. In Figure 10-17, 
PROGA and PROGB both have a data set to be defined at load time 
(?? entry in DS= lists). Assuming PROGA is loaded from a terminal, 
the terminal operator will supply the missing data set name for PROGA. 
PROGB, however, is loaded by PROGA, and therefore PROGA must 
pass PROGB's missing data set name. 

At location LD1 in PROGA, FILEZ is defined in the DS= list of the 
LOAD statement. When the LOAD is executed, FILEZ will be sub- 
stituted for the ?? entry in the PROGRAM statement's DS= list for 
PROGB. 
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J 



PROGA 
ASTART 



LDl 
LD2 



PROGRAM ASTART, DS=(??,FILEA) 



LOAD 
LOAD 



PROGSTOP 



PR0GB,DS=(FILEZ),ERR0R=E3 
PR0GB,DS=(DS1),ERR0R=E3 






ENDPROG 
END 



PROGB PROGRAM BSTART,DS=(FILEB,??) 
BSTART READ DS1,BUF,END=ENDB,ERR0R=ERRB 



WRITE DS2,BUF,END=ENDB,ERR0R=ERRB 



PROGSTOP 





ENDPROG 
END 



Figure 10-17. Program load — data set passing 

PROGB will READ from FILEB, and WRITE to FILEZ. Note that 
data set names defined in the DS= list of a LOAD statement do not 
have to exist in the loading program's PROGRAM statement DS= 
list. 
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Data set names that are in the DS= list of the loading program's 

PROGRAM statement can be passed using the actual name, or by using /- 

the symbolic positional reference DSx. At LD2 in PROGA (Figure i 

10-17), PROGB Is again loaded, passing the data set DS1. This refers 

to the first entry In the DS= list in PROGRA's PROGRAM statement, 

which is coded as ??. Again assuming this data set name was supplied 

by a terminal operator when PROGA was loaded, that same name will 

be passed through to PROGB, becoming the data set used by PROGB 

for the WRITE operation. If DS2 instead of DS1 were coded, FILEA 

would have been passed. 

When programs using disk/diskette I/O are loaded as overlays, all 
names of data sets used by the overlay program must be passed by the 
loading program, and the data set names that are passed must be 
entries in the DS= list of the loading program's PROGRAM statement. 
In Figure 10-18, the PROGRAM statement for PROGA defines 
PROGB as an overlay program (PGMS=PROGB). The LOAD state- 
ment at LD3 will load PROGB as an overlay, because the program 
name specified is PGM1, a positional reference to the PGMS= list. 
PROGB uses two data sets, so two data set names are passed to 
PROGB in the LOAD statement's DS= list: DS2 and DS1, which 
reference FILEA and ?? in the DS= list for PROGA. When passing 
data set names to an overlay program, the LOAD statement must 
use the DSx positional references. 

All data sets used by an overlay program must be passed to the 
overlay by the loading program, and therefore all data set names 
in the DS= list of the PROGRAM statement of a program loaded 
as an overlay are treated as though they were ?? entries. For 
example, if PROGB is loaded as an overlay, FILEB will not be 
used, unless it is passed by the LOAD statement in the loading 
program. 
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PROGA PROGRAM ASTART,DS=(??,FILEA) ,PGMS=PROGB 
ASTART 



LD3 LOAD PGM1,DS=(DS2,DS1),ERR0R=E3,EVENT=BD0NE 
WTl WAIT BDONE 

PROGSTOP 
BDONE ECB 





ENDPROG 
END 



PROGB PROGRAM BSTART,DS=(FILEB,??) 
BSTART READ DS1,BUF,END=ENDB,ERR0R=ERRB 



WRITE DS2,BUF,END=ENDB,ERR0R=ERRB 



PROGSTOP 






ENDPROG 
END 



Figure 10-18. Overlay load — data set passing 
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In Figure 10-18, if the terminal operator loading PROGA ($L PROGA) 
responds to the DS1=(NAME,V0LUME): prompt by entering 
Fl LEG, PROGA will execute as though the DS= list in the 
PROGRAM statement were coded DS=(FILEC,FILEA). In the 
DS= list of the LOAD at LD3, the first entry is DS2. This first 
position in the LOAD statement's DS= list corresponds to the first 
position In the DS= list for PROGB. The DS2 references the second 
entry in the DS= list of PROGA's PROGRAM statement, which is 
coded as Fl LEA. The data set name Fl LEA is therefore passed to 
PROGB as the first entry of the DS= list in the PROGRAM statement 
for PROGB. Similarly, the second entry in the LOAD statement's 
DS= list will pass Fl LEG, the DS1 data set name entered by the 
operator, to the second entry in the DS= list for PROGB. PROGB 
will execute as though the DS= list in the PROGRAM statement 
werecodedas"DS={FILEA,FILEC)". The READ will be from 
FILEA, and the WRITE to FILEC. 
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DISK/DISKETTE I/O REVIEW EXERCISE-QUESTIONS 

^~^^ 1. How many volumes may be defined on a 4962/4963 Disk Storage 
V_^ Unit? 

2. Which of the following choices, when used to complete the 
statement below, makes the statement not true? 

"The DS= list in a PROGRAM statement . . . 

a. ... must contain an entry for each data set used by the 
program." 

b. ... may contain up to nine entries." 

c. ... may specify data sets resident on other than the iPL 
volume." 

d. ... is used to define the names of any overlay programs that 
may be loaded by the program." 

e. ... may have entries for data sets that will not be defined 
until load time." 

All of the remaining "Questions for Review" refer to the coding 
example in Figure 10-19. 
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PROGl 


PROGRAM 


G0,DS=(DSET1,DSET2,DSET4,DSET9),PGMS=P2 


GO 


READ 


DS3, BUFA, NBR, RCRD, END=E1,ERR0R=E2 


RD2 


READ 




IFl 


IF 


( , , ), GOTO, El 


IF2 


IF 


("",","), GOTO, E2 


Nl 


NOTE 


DS3,DS3VAL 


LDl 


LOAD 


P2,DS=( , ),ERROR=LDERR 


LD2 


LOAD 


,DS=r T", ),ERROR=LDERR 




PROGSTOP 




BUFA 


BUFFER 


, BYTES 


DS3VAL 


DATA 


F^O' 


NBR 


DATA 


F'2' 


RCRD 


DATA 

ENDPROG 
END 


F'5' 



P2 
PGO 



PR2 



PR3 



BUFF 



PROGRAM 
READ 



READ 



READ 



PG0,DS=(??,DSET3,??) 
DS3,BUFF 



DS1,BUFF 



DS2,BUFF 



PROGSTOP 
BUFFER 128 
ENDPROG 
END 



Figure 10-19. Review problem 
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a. How many records will be read by the READ at location GO? 

b. What is the name of the data set used? 

c. What is the relative record number of the first record that will 
be read? 

d. What should be coded as the first operand of the BUFFER 
statement at location BUFA? 

Answers: a. 

b 



c. 

d 

Code the READ at RD2 to read a single record (let count take 
default) into BUFA. The record should be the first relative 
record (let reirecno take default) in data set DSET4. Do not 
code the END=or ERROR= operands. Code the IF at IF1 
to check for end-of-data set condition, and the IF at I F2 to 
check for other errors. 

Answer: 



RD2 READ 

IF1 IF ( , ),G0T0,E1 

IF2 IF ( ),G0T0,E2 



After executing the NOTE instruction at N1, what will be the 
value of location DS3VAL? 

Answer: 



Code the LOAD instruction at location LD1 so that when program 
P2 executes, the READ at PGO will use data set DSET5, the 
READ at PR2 will use DSET9, and the READ at PR3 will read 
from DSET3. 

Answer: 



LD1 LOAD P2,DS=( , ),ERROR=LDERR 
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Code the LOAD at location LD2 to load P2 as an overlay 
program. In program P2, the READ at PGO should use 
DSET1, the READ at PR2 data set DSET2, and the READ 
at PR3, data set DSET4. 

Answer: 



LD2 LOAD ,DS={ , ),ERROR=LDERR 

8. The LOAD at LD2 Is a load of an overlay program. What 
must be added to PR0G1 to ensure the proper termination- 
of-execution sequence between P2, the overlay program, 
and PR0G1, the loading program? 

Answer: 
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DISK/DISKETTE I/O REVIEW EXERCISE-ANSWERS 



1. Each 4962/4963 may have as many volumes as required defined, 
within the physical size limitations of the device. 

2. All choices except choice "d" will complete the statement 
truthfully. The "PGI\/IS=" keyword operand is used to 
define the overlay programs. 

3. a. 2 records will be read {count=NBR=2) 

b. DSET4 will be used. DSET4 is the third entry in the DS= 
list, and is referenced by DS3 in the READ at GO. 

c. relative record number 5 (relrecno=RCRD=5) 

d. 512 or more, because two 256 byte records are being read 
(NBR=2). 



RD2 


READ 


DS3,BUFA 


IF1 


IF 


{DS3,EQ,10),GOTO,E1 


IF2 


IF 


(DS3,NE,-1),GOTO,E2 



5. DS3VAL will contain 2, because the next record pointer is 
updated by +1 following the READ at R2. 

6. LD1 LOAD KdS=(DS4,DSET5),ERROR=LDERR 

7. LD2 LOAD PGM1,DS=(DS2,DS3,DS1),ERROR=LDERR 

8. The LOAD at LD2 should have the EVENT= operand coded, 
declaring an event name. An ECB with that event name should 
also be coded, and a WAIT on that event name should occur 
prior to the PROGSTOP. 
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Section 11. Terminal I/O 



TERMINAL STATEMENT 



OBJECTIVES: After completing this section, the student should be 
able to: 

1. Describe roll screen and static screen operation 

2. Use PRINTEXT, PRINTIME, PRINDATE, and PRINTNUM 
instructions to display data on a terminal 

3. Use READTEXT and GETVALUE instructions to read data 
from a terminal 

4. Understand the purpose of specialized terminal instructions 
such as QUESTION, TERMCTRL, etc. 

The Event Driven Executive terminal support is designed to be as 
device independent as possible. With few exceptions, the user need 
not be concerned with what type of device is being driven by terminal 
functions coded in the program. The same sequence of terminal 
output instructions, for instance, may be used to print data on a 
matrix or line printer, on a locally attached TTY device or a remote 
ACCA terminal, or to display the data on an electronic display 
screen device. 

The specific terminal support applies to the IBM 4978, 4979 and 3101 
displays. The 3101 Models 10, 11, 12 and 13 operate in character (roll 
screen) mode. A 3101 operating in character mode, attached via the 
teletypewriter adapter card, can be used as the system console. The 
3101 Models 20, 21 , 22 and 23 can operate in either character mode or 
block (static screen) mode. To be used as a static screen (block mode) 
device, the 3101 M2 must be attached via the single line or multiline 
asynchronous communications adapter card. Discussions in this section 
which refer to a 3101 operating in block mode will be designated as 
3101 M2. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
System Guide (SC34-1702), "TERMINAL Configuration Statement." 

Terminals are defined to the system using the TERMINAL system 
configuration statement. This statement generates system control 
blocks and tables containing the logical and physical variables 
necessary to operate the terminal. Among the physical variables 
described in the TERMINAL statement operands are the type of 
terminal (TTY, printer, display, etc.), its hardware address, the type 
of transmission code used, and other hardware related parameters 
unique to the device being defined. 
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The high degree of device independence is achieved in part by treating 
all terminals as though they were line printers, differing only in their 
page sizes (forms length) and margin settings, also defined by 
TERMINAL statement operands. 



V 



Roll Screens 



NHIST= Operand 



The page size for an IBM 4978/4979/3101 terminal is 24, the maximum 
number of lines that can be displayed on the screen. The 
4978/4979/3101 Displays can be operated as roll screen or static screen 
devices (SCREEN= operand in TERMINAL statement). A roll 
screen device operates in much the same way as a typewriter. 
Assuming a blank screen (clean page in typewriter) to start, data 
is displayed line by line, beginning with line at the top of the 
screen and continuing through line 23 at the bottom of the screen, 
just as a typewritten page is filled from top to bottom. When a 
page being typed is full, the completed page is removed, a clean 
page is inserted, and typing continues at the top of the new page. 
When a roll screen device's screen is full (all 24 lines used), an 
attempt to display the next line results in removal of the old screen 
(screen is erased) and display of the new line on line 0, at the 
top of the screen. 



Unlike a typewriter, the display is not a hardcopy device, and therefore 
the information on the old screen (previous page) cannot be referred 
to after it has been erased. If an operator entry is expected and the 
operator prompts describing that entry were displayed on a now-erased 
previous screen, time could be wasted in looking up the input request 
in a reference book, or in requesting that the program repeat the 
display of the prompt. 

This potential problem is avoided by coding the NHIST= operand of 
the TERMINAL statement to reserve part of the screen as a history 
area. NHIST= is the number of history lines you wish to reserve. 
For example, if NHIST=12 is coded, the top twelve lines of the 
screen are reserved for a history area (physical lines through 11), and 
the bottom twelve lines (physical lines 12 through 23) as a work area, 
operating in the normal roll screen fashion. (The 4979 Display 
supported by the starter system is defined with NHIST=12, and 
NHIST=12 will be the default for user defined 4978/4979 displays if 
NHIST= is left uncoded. NHIST defaults to for 3101.) 

Since all terminals, including electronic display screens, are treated 
logically as printers, forms control commands are used to position 
displayed output on a screen, just as lines and spaces may be skipped 
on a printout to position a print line on a page. Although physically 
(with NHIST=12) the work area occupies lines 12 through 23, logically, 
for purposes of forms control interpretation, they are treated as 
lines through eleven. Display information directed to line will be 
displayed on physical line 12, the top of the work area. 
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Again beginning witii a blank screen, successive lines are displayed 
starting at the top of the work area, and continuing to the bottom 
of the screen. With the work area full, an attempt to display the 
next line will cause: 

1. the information displayed in the "work area" to be moved up 
into the "history area", (physical lines through 11). 

2. the "work area" (lines 12-23) to be erased 

3. display of the new line on physical line 12, the top of the 
work area. 

Each time the work area is exceeded, the information displayed there 
is moved up into the history area, thereby retaining some past history 
for viewing. The work area and history area do not have to be of 
equal size; you may code NHIST= to retain as few as lines of 
previous data, or as many as 23 lines. 



Static Screens 



Terminals operated as roll screen devices are usually used in an 
interactive mode, to communicate between a program and an 
operator. Operator prompts and their associated responses are ex- 
changed on a line by line basis. The display of a new line, or the read 
of an operator entry is usually initiated by the operator pressing a 
terminal control key such as ENTER or one of the program function 
keys, indicating that the operation can proceed. A common example 
is the series of prompts and replies that are exchanged between 
program and operator when using the Event Driven Executive 
utilities. 

When a 4978/4979/3101 U2 Display is defined as a static screen device 
(SCREEN= operand in TERMINAL statement), the screen Is treated 
as a page of information. The screen may be formatted with pre- 
determined operator prompts (Input field names), and these areas 
may be designated as "protected", preventing accidental overlay 
by Input data. The input fields of a static screen are usually 
filled in by the operator without interaction with the program. 
Terminal operation keys such as TAB, BACKSPACE, or the cursor 
positioning keys are used to move the cursor to the required input 
field positions. 

When all required input fields have been entered, the operator 
presses the ENTER key (or a designated Program Function key) 
to signal the program that the page is complete. The program then 
reads all the information on the screen, erases the screen, and dis- 
plays a new page (screen with prompts, but blank Input fields) for 
the operator to fill. 

Terminals operated as static screen devices must be either IBM 4978, 
4979 or 3101 M2 Displays, as some of the specialized Instructions used 
with static screens can be Interpreted only by the 4978/4979/3101 M2 
hardware. Other electronic display screen devices and, of course, all 
hardcopy terminals, are operated as roll screens. 
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ENQT/DEQT INSTRUCTIONS 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "ENQT", "DEQT." 

When a program is loaded from a terminal, that terminal is dynami- 
cally designated by the system as the terminal to be used by terminal 
I/O instructions in the program. Each terminal I/O instruction auto- 
matically has exclusive use of the terminal during the execution of 
that individual operation; only one task at a time is allowed to per- 
form I/O on the terminal. 

If more than one task is using the terminal, terminal operations 
from different tasks could become interspersed. In cases where this 
is undesirable, the ENQT (enqueue terminal) facility may be used to 
reserve the terminal for the exclusive use of a task, thereby pre- 
venting other tasks from using the terminal until the task issuing 
the ENQT releases it (DEQT). 



label 



name,BUSY= 



OPTIONAL MUST BE CODED OPTIONAL 
Figure 11-1. ENQT format 

If ENQT is coded without the optional name operand, the default 
is to the terminal that loaded the program. The task issuing the 
ENQT will acquire exclusive control of the loading terminal, and will 
retain control until executing a DEQT instruction. If the terminal is 
busy (enqueued by another task) when the ENQT is executed, the 
task issuing the ENQT is placed in a wait state, queued up waiting for 
the terminal to become available. If you do not wish to be queued 
if the terminal is busy, the BUSY= operand should be coded with the 
label of the instruction to which you wish control transferred. 

The ENQT may also be used to gain exclusive control of a terminal 
other than the loading terminal. The symbolic name assigned to a 
terminal is the name coded as the label of the TERMINAL statement 
defining the device. Coding a name in the label field automatically 
defines the terminal to the system as a global resource that may be 
enqueued by user programs (ENQT). There are three symbolic ter- 
minal names that have special significance, as they are used by the 
supervisor or system utility programs: 

1 . $SYSLOG this is the name of the system logging device or 
operator station, and must be defined in every system. In the 
system configuration statements used to generate the supplied 
supervisor, $SYSLOG is the label of a TERMINAL statement 
defining a 4978 Display. 
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^-~^\ 



2. $SYSLOGA This is the name of the alternate system logging 
device. In the event that unrecoverable errors prevent use of 
$SYSLOG, the system will use the $SYSLOGA terminal as the 
system logging device/operator station. If defined ($SYSLOGA 
is optional), this device should be a terminal with keyboard 
capability, not just a printer. The supplied supervisor 
$SYSLOGA terminal is a TTY device. 

3. $SYSPRTR This is the name of the system printer, and is also 
optional. If defined, the output from some system programs will 
be directed to this device. In the supplied supervisor, 
$SYSPRTR is defined as a 4974 matrix printer. 

In addition to being used by the system, these devices may also be 
enqueued (ENQT) by user programs. In Figure 1 1-2, the ENQT/DEQT 
coding example refers to the terminals defined in the TERMINAL 
configuration statements shown at the top of the illustration. For 
simplicity, only the required TERMINAL statement operands are 
coded; all other operands are default values. 



$SYSLOG TERMINAL DEVICE=4979,ADDRESS=04 

$SYSPRTR TERMINAL DEVICE=4974,ADDRESS=01 

$SYSLOGA TERMINAL DEVICE=TTY,ADDRESS=00 

DSPLYl TERMINAL DEVICE=TTY,ADDRESS=10,END=YES 



TERMTASK 
START 


PROGRAM 
ENQT 


START 


Dl 
E2 
E3 


DEQT 
ENQT 
ENQT 


$SYSPRTR,BUSY=E3 
SSYSLOG 


D2 


DEQT 

PROGSTOP 
ENDPROG 
END 





Figure 11-2. ENQT/DEQT operation 

Assuming that the loading terminal is the TTY device DSPLYl, the 
ENQT instruction at location START will acquire exclusive control 
and retain control until execution of the DEQT at Dl. No name 
operand is coded for the ENQT, so the loading terminal DSPLYl 
is enqueued, thereby preventing other tasks from using DSPLYl, 
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lOCB STATEMENT 



The ENQT at E2 is directed at the 4974 matrix printer, $SYSPRTR. 
If the matrix printer is already in use (enqueued), control is trans- 
ferred to the next instruction at location E3 (BUSY=E3). This is an 
attempt to enqueue the 4979 display terminal $SYSLOG. If 
$SYSLOG Is already enqueued, TERMTASK will be placed in a wait 
state, waiting until the terminal becomes available. In effect, the two 
ENQT statements at E2 and E3 may be interpreted as "try to get the 
system printer; if it is in use, get $SYSLOG instead and use it." 

If the ENQT at E2 executes successfully, acquiring control of $SYSPRTR, 
the ENQT at E3 will execute as a no-op. When an ENQT for a given 
terminal has successfully executed and enqueued that terminal, 
ensuing ENQTs issued by the same task directed to terminals other than 
the terminal already enqueued are ignored. The system allows any one 
task to enqueue only a single terminal at a time. To switch from an 
already enqueued terminal to a different terminal, a DEQT must be 
issued before the ENQT for the new device is executed. DEQT 
commands are non-specific (no "name" operand), acting upon 
whatever terminal is currently enqueued by the issuing task. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "lOCB." 

One of the system control blocks generated by assembly of the 

TERMINAL system configuration statement Is called an Input .---s^ 

Output Control Block (lOCB). A terminal lOCB contains infor- f ' 

mation such as the terminal's forms configuration (page size, margins), 

operating mode (static, roll), and history area size (NHIST= operand). 

A terminal is not restricted to the values coded for these parameters 

In the TERMINAL statement; they can be dynamically changed by a 

user program. 

In Figure 1 1-3, a 4979 Display called DSPLY1 is defined in the 
TERMINAL statement at the top of the illustration. As you know from 
the previous discussion of roll screen operation, the NHIST= 
default value (for 4978/4979 Displays) is 12, dividing the screen 
into a history area and a work area of twelve lines each. 

In TERMPROG (Figure 11-3), assume the user wants a screen that 
operates so that each new line is displayed on the last (bottom) line of 
the screen, forcing the previously displayed 24 lines up one for each 
new line displayed. This will cause the screen to act as a continuous 
scroll, with each new line forcing the oldest previous line off the 
screen at the top. 
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DSPLYl TERMINAL DEVICE=4979,ADDRESS=20 



TERMPROG 

NEWHIST 

SCROLL 



DONE 



PROGRAM 

lOCB 

ENQT 



DEQT 

PROGSTOP 
ENDPROG 
END 



SCROLL 

DSPLYl, NHIST=23 

NEWHIST 



Figure 11-3. lOCB/ENQT 

To operate in this way, a history area of 23 lines is required, leaving 
a one line work area for new entries. At location NEWHIST is a 
user-coded IOCS, which references terminal DSPLYl, and defines 
NHIST= as 23. The ENQT at SCROLL references the lOCB label 
NEWHIST. Execution of the ENQT acquires exclusive control of, 
and puts the user-coded lOCB in effect for, the named terminal, 
DSPLYl. (If no terminal name is coded, the system will default to 
the loading terminal.) Until execution of the DEQT at DONE, DSPLYl 
will operate with NHIST=23. The DEQT will cause DSPLYl to revert 
back to the lOCB values generated by the TERMINAL system 
configuration statement. 

In the same manner, 4978/4979 Displays that are defined in 
TERMINAL statements as roll screen devices {SCREEN= default Is 
ROLL) may be dynamically enqueued for static screen operation by 
a user program. Because Event Driven Executive system and utility 
programs expect a roll screen configuration on terminals they commu- 
nicate with, you should define the terminals as roll screen devices 
in the TERMINAL statements, and enqueue them for static screen 
operation (ENQT/IOCB) when required. The exception is where a 
terminal is never used to communicate with the supervisor or system 
utilities (always used exclusively as a user static screen application 
terminal). 

The only terminals that may be enqueued directly, by coding the 
label of the TERMINAL statement in the name operand of an ENQT 
statement, are the two special system terminals, $SYSLOG 
and $SYSPRTR. User-defined terminals and $SYSLOGA are enqueued 
by coding the label of the TERMINAL statement in the name operand 
of an lOCB statement, and referencing the lOCB label In the ENQT 
name operand. 
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DATA REPRESENTATION 



PRINTEXT INSTRUCTION 



In general, alphameric (text) data to be written to a terminal is 
represented in storage as an EBCDIC character string. The system 
automatically converts this character string into the code required 
by a specific terminal, when an output operation directed to that 
terminal is executed. (For some specialized terminals employing 
unique control characters imbedded within the text, translation can 
be inhibited.) 

In a similar manner, input from a terminal is translated into an 
EBCDIC character string by terminal read operations. For both input 
and output operations Involving text data, a user-defined storage area 
is used to hold the EBCDIC character string. This storage area may 
be implicit, as when an output message (prompt) is coded as an 
integral part of an output or input command, or explicit, when an 
output or input operation specifies the label of a user-defined 
TEXT statement. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "PRINTEXT." 

The PRINTEXT instruction Is used to print (display) messages on a 
terminal, and/or to control forms movement (position display/ 
cursor on screen). 



label 



PRINTEXT I msg,SKIP=,LINE=,SPACES=,MODE=,PROTECT= 



OPTIONAL MUST BE CODED AT LEAST ONE 

OPERAND 
MUST BE CODED 

Figure 11-4. PRINTEXT format 

At least one of the PRINTEXT operands must be coded. The msg 
operand may be coded as the actual data (enclosed in apostrophes), 
or may be the label of a TEXT statement containing the message. 

In Figure 1 1-5, both PRINTEXT instructions will execute the same; 
the message "READY FOR INPUT" will be written to the loading 
terminal (ENQT with no terminal name or lOCB label specified). 
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TERMPROG PROGRAM START 



START ENQT 

PI PRINTEXT 'READY FOR INPUT 



P2 PRINTEXT Tl 

DEQT 

PROGSTOP 
Tl TEXT 'READY FOR INPUT' 

ENDPROG 

END 

Figure 11-5. "msg" operand 

In the PRINTEXT at PI the storage area containing the EBCDIC 
character string READY FOR INPUT is implicitly generated (assembled) 
as part of the PRINTEXT instruction; the PRINTEXT at P2 references 
the user-defined (explicit) string at location Tl. 

Terminals are buffered devices. Data to be displayed on a terminal 
is transmitted to the terminal's buffer, and remains in the buffer until 
some condition occurs that forces the contents of the buffer to be 
displayed. Among the several buffer forcing conditions that can cause 
the contents of a buffer to be displayed or printed is the execution 
of a PRINTEXT with the LINE= or SKIP= forms control operands 
coded. 



jlabeT PRINTEXT msg, SKIP=,LINE=,SPACES=,MODE=, PROTECT^ 

Figure 11-6. Forms control operands 

The SPACES= forms control operand positions the message or cursor 
within a line, but does not force the device buffer. SKIP=, LINE=, 
and SPACES= may be coded as the only operand(s), or may be used 
with other operands, including msg. When coded with msg, the forms 
control operation is executed before the msg text is transmitted to 
the buffer. 

In Figure 11-7, assume the loading terminal Is $SYSLOG, a 4979 
Display. To better illustrate the effect of the forms control operands, 
the ENQT at START references an lOCB which sets NHIST= to 0. 
The entire screen will now operate as a roll screen work area. 
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TERMTEST 


PROGRAM 


START 


START 


ENQT 


lOCBl 


PI 


PRINTEXT 


LINE=0 


P2 


PRINTEXT 


'MESSAGE 1 ',SPACES=10,LINE=5 


P3 


PRINTEXT 


'MESSAGE 2 ' ,SPACES=20,SKIP=2 


P4 


PRINTEXT 


'MESSAGE 3 ' ,SPACES=70 


P5 


PRINTEXT 


MESSAGE 4 ',SKIP=1 


P6 


PRINTEXT 


'MESSAGE 5 ' ,SPACES=5 


P7 


PRINTEXT 


Tl 


P8 


PRINTEXT 


T2 


P9 


PRINTEXT 

DEQT 

PROGSTOP 


'TEST ENDED', SKIP=1 


Tl 


TEXT 


'MESSAGE 6 ',LENGTH=15 


T2 


TEXT 


'MESSAGE 7 ' 


lOCBl 


lOCB 

ENDPROG 

END 


$SYSLOG,NHIST=0 



Figure 11-7. PRINTEXT example 

The PRINTEXT at PI Illustrates a forms control operand coded 
without the msg command. Since the example is using a 4979 
Display, this command readies the screen for display on line 0. If 
directed to a hardcopy device, this would be the equivalent of a 
page eject command. 

The PRINTEXT at P2 has both msg operand (text) and forms control 
operands coded. The forms control operation will be executed first. 
The LINE=5 forces the contents of the buffer onto line 0, and clears 
the buffer . (Because no msg operand was coded in the previous 
PRINTEXT (PI), the buffer is empty, and nothing is displayed on 
line 0.) Next, the terminal is readied for display on line 5. 

The SPACES=10 skips over the first ten buffer positions, and 
MESSAGE 1 goes in the next ten buffer positions (11 through 20). 
The text MESSAGE 1 is still in the buffer; no data has yet been 
displayed. 

The PRINTEXT at P3 performs the following functions: 

1. The SKIP=2 forms control operand forces the buffer, displaying 
MESSAGE 1 on line 5. 

2. The cursor is positioned for line 7 (SKIP=2), and the text 
MESSAGE 2 is placed in buffer positions 21 through 30, 
skipping over the first 20 buffer positions (SPACES=20). 

After execution of the PRINTEXT at P3, the display screen is as 
shown In Figure 11-8. 
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LINES 




CHARACTER 
POSITIONS 



1111111111 2222222222333333333344444444445555 
12345678901234567890123456789012345678901234567890123 



78901234567890 



Figure 11-8. After P3 execution 

The PRINTEXT at P4 (Figure 1 1-7) has no LINE= or SKIP= 
operands coded, so the buffer is not forced out. The text MESSAGE ; 
is concatenated to the current contents of the buffer, iVlESSAGE 2. 
MESSAGE 2 is in buffer positions 21 through 30. The SPACES=70 
operand in the PRINTEXT at P4 skips over 70 buffer positions, 
beginning with position 31. The text MESSAGE 3 will therefore 
occupy buffer positions 101 through 110. 

The display screen is only 80 positions wide. Text data positioned 
outside the line length of a terminal is truncated, and therefore 
MESSAGE 3 will not be displayed. {OVFLINE=YES must be coded 
in the TERMINAL statement to allow display of text positioned 
outside the right margin.) 

The PRINTEXT at P5 (Figure 11-7) performs the following functions. 

1. displays MESSAGE 2 In positions 21 through 30 on line 7 
(SKIP=1 forces the buffer). 

2. specifies line 8 for the next output line (SKIP=1) and places 
MESSAGE 4 in the first fifteen buffer positions. Figure 11-9 
shows the screen after execution of the PRINTEXT at P5. 
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LINES 


1 
2 
3 
4 
5 
6 
7 
8 

g 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 

CHARACTER 
POSITIONS 



1 1 \ 



MESSAGE 1 



MESSAGE 2 




11111111 1 12222222222333333333344444444445555 
12345678901234567890123456789012345678901234567890123 



66677777777778 
78901234567890 



Figure 11-9. After P5 execution 

The PRINTEXT at P6 (Figure 1 1-7) skips buffer positions 16 through 

20 {SPACES=5) and concatenates the text MESSAGE 5 into positions 

21 through 30. 

Explicitly defined text is also concatenated. The PRINTEXT at 
P7 references the TEXT statement at T1. MESSAGE 6 is added to 
the buffer in positions 31 through 40. Although the text buffer at T1 
is 15 characters long (LENGTH=15), only the data between the 
apostrophes is moved into the buffer. The PRINTEXT at P8 adds 
MESSAGE 7 in positions 41 through 50. 

When the PRINTEXT at P9 executes, the buffer contents are dis- 
played on line 8, and the cursor is moved to line 9 (SKIP=1). 
TEXT ENDED is placed in the first ten buffer positions. The screen 
now looks like Figure 1 1-10. 
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8 
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12 

13 

14 

15 
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21 
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! \ 



MESSAGE 1 



MESSAGE 4 



MESSAGE 
MESSAGE 



MESSAGE 6 MESSAGE 7 




1111111111 2222222222333333333344444444445555 66677777777778 
12345678901234567890123456789012345678901234567890123 78901234567890 



Figure 11-10. After P9 execution 



There is no PRINTEXT with a forms control operand following the 
PRINTEXT at P9, but the TEST ENDED message will still be trans- 
ferred from the buffer and displayed. Execution of a DEQT, like 
a LiNE= or SKIP= forms operation, is a buffer-forcing condition. 

In the example in Figure 1 1-7, the program would still execute 
correctly if the DEQT were not coded. The PROGSTOP statement 
will dequeue the terminal (implicit DEQT) and force the buffer. You 
should still get in the habit of coding explicit DEQTs, because the system 
cannot be relied upon to perform such housekeeping chores in all cases. 
For example, if the terminal instructions in Figure 11-7 were part of 
a secondary task and the DEQT were left out, the terminal would 
remain enqueued and unavailable to the rest of the system after the 
secondary task completed execution. Unlike the PROGSTOP, 
execution of an ENDTASK instruction does not automatically 
issue a DEQT. 
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Figure 11-11. After PI through DEQT 



Figure 11-11 shows the screen after ail PRINTEXT instructions and the 
DEQT have been executed. 

When writing to roll screen devices, an at sign {@) imbedded in the 
text will be interpreted as a new line or "carriage return" control 
character. In Figure 11-12, the programs T1 and T2 are logically 
equivalent. 



Tl 
SI 
PI 
P2 
D 



PROGRAM 

ENQT 

PRINTEXT 

PRINTEXT 

DEQT 

PROGSTOP 

ENDPROG 

END 



SI 



FIRST MSG' 

2ND MSG',SKIP=1 



T2 


PROGRAM 


S2 


S2 


ENQT 




XI 


PRINTEXT 


'FIRST MSG 


X2 


PRINTEXT 


'(a2ND MSG' 


X 


DEQT 

PROGSTOP 
ENDPROG 
END 





Figure 11-12. ©operation 



The PRINTEXT statements at PI and XI are identical, and will put 
the text FIRST MSG in the buffer. In program Tl, the SKI P=1 
operand in the PRINTEXT at P2 will force the buffer, displaying 
FIRST MSG on the current line, and move the display position to the 
next line. 2ND MSG will be placed in the buffer. 
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The @ imbedded in the msg operand of the PRINTEXT at X2 (program 
/^-~-s T2) has the same effect as SKIP=1, forcing the buffer contents onto 

. ) the current line, and moving the display position to the next line. Unlike 

the SKIP= and LINE= operands, the @ or new line operation is executed 
at the time it is encountered in the character buffer. The SKIP=1 
operand in task T1 executes before 2ND MSG is transferred to the 
buffer, because SKIP= and LINE= operations always execute before 
the buffer transfer. The new line operation in task T2 is also 
executed before 2ND MSG is transferred to the buffer because the 
@ precedes the 2ND MSG text. Were the @ imbedded further along 
in the text string, characters to the left of the @ would be con- 
catenated to the FIRST MSG text and displayed on the same line as 
FIRST MSG, while characters to the right of @ (as shown in Figure 
11-12) would be displayed on the next line. 

In both T1 and T2, the 2ND MSG text is moved out of the buffer 
and displayed by execution of the DEQT (D or X). 

1 abel PRINTEXT msg /SKIP= >LrNE= ,SPACES= ,MODE= ,PRpTEGt=| 

Figure 11-13. MODE= operand 

When you want the @ character to act as a normal text character 
(not to be interpreted as a new line character), the MODE= keyword 
operand should be coded as MODE=LINE. 

The MODE= operand has a special function when used with 
PRINTEXT instructions directed to static screen devices (4978s or 
4979s) with protected data areas. 

label PRINTEXT msg,SKIP=,LINE=,SPACES=,MODE=,PROTECT= 

Figure 11-14. PROTECT= operand 

\ 

Protected data is written to a static screen by coding the PROTECT= 
keyword operand as PROTECT=YES. If MODE=LINE is coded in a 
subsequent PRINTEXT that is writing to a line containing protected 
data, the protected areas are automatically skipped over when the 
buffer is transferred to the screen. 
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READTEXT INSTRUCTION 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "READTEXT." 

The READTEXT instruction is used to read an alphameric text 
string, entered by a terminal operator, into a user-defined text buffer 
in storage. 



label I READTEXT locipmsg,PROMPT=,MODE=,SKIP=,LINE= ,SPACES= 

OPTIONAL MUST BE CODED OPTIONAL 

Figure 11-16. READTEXT format 

The loc operand is the label of the first location of the storage area 
that will receive the EBCDIC character string from the terminal. 
The READTEXT instruction (also PRINTEXT) operates with TEXT 
statements, using the length and count control bytes that precede a 
character buffer generated by a TEXT statement assembly. The loc 
operand is, therefore, usually the label of a TEXT statement; if it 
is coded as the label of a character buffer not generated by a TEXT 
statement, the user must set up the control bytes preceding the 
buffer to meet TEXT statement conventions. 



label READTEXT loc,pmsg,PROMPT=,MODE=,SKIP=,LINE=,SPACES= 

Figure 11-17. pmsg and PROMPT= operands 

The pmsg operand is the prompt message (enclosed in apostrophes) 
or the label of a TEXT statement containing the prompt message 
you wish displayed before pausing to accept the operator input. The 
pmsg operand works in conjunction with the PROMPT= keyword 
operand. If PROMPT= is coded as PROMPT=UNCOND (which is the 
default if it is not coded), the prompt message specified by the pmsg 
operand will always be written. If PROMPT= is coded as 
PROMPT=COND, advance input is allowed, and the prompt message 
may or may not be written. Advance input allows an operator to 
enter more information on a line than is suggested by the prompt 
message for that line. An operator familiar with a certain prompt/ 
response sequence can enter all items in response to the first prompt, 
thereby skipping succeeding prompt messages. The use of 
PROMPT=COND will be illustrated in an example later in this section. 

label READTEXT loc, pmsg, PROMPT=,MODE=,SKIP=,LINE=,SPACES=: 

Figure 11-18. MODE= operand 
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The MODE= operand may be coded MODE=WORD (the default, 
if notcoded) or MODE=LINE. If MOD E=WORD is coded, transfer 
) of data from a terminal buffer to a user text buffer is terminated by: 

1. a blank (space) character in the input field 

2. exhaustion of the character count In the user text buffer (input 
exceeding input buffer length — truncation of input occurs) 

3. if directed to a static screen, the beginning of a protected field. 

If MODE=LINE is coded, the input data may contain imbedded 
blanks without terminating the transfer. If a READTEXT with 
MODE=LINE is directed to a static screen, protected areas do not 
occupy user TEXT buffer positions; only the unprotected areas are 
read. 

label READTEXT loc,pmsg,PROMPT=,MODE=,SKIP=,LINE=,SPACES= 

Figure 11-19. Forms control operands 

The SKIP=, LINE=, and SPACES= operands perform the same function 
as with the PRINTEXT instruction, specifying the line and position 
within the line where the next operation will take place. 

READTEXT operation, including some of the operand variations 
just discussed, is illustrated in Figure 1 1-20. Assuming the program 
is loaded from a 4979 Display, the ENQT at START changes the 
(defaulted) history area from 12 lines to none, and enqueues the 
terminal. The LINE=3 operand in the READTEXT at R1 readies 
the terminal for display on line 3, and the loc operand specifies a 
20-character text buffer at location T1 as the storage area that will 
receive the input data. 

The READTEXT at R2 specifies T2 as the input buffer. The pmsg 
operand is the label of the TEXT statement T3, containing the 
prompt message ENTER PART NBR:. 

When the READTEXT at R1 executes, the prompt message ENTER 
PART NAME will be displayed on line 3, the cursor will be positioned 
just following the colon in the prompt message, and task TERM will 
be suspended, waiting for operator input. 

As an operator keys an entry onto the screen, there is no program 
involvement. The actual input operation (transfer of terminal buffer 
information to storage) does not begin until the program is signalled 
that the input is complete. When the operator is satisfied that the 
input is correct, he/she will press the ENTER key, initiating the 
actual transfer. (The Program Function keys are also interrupt 
generating, and are frequently used in operator/terminal communica- 
tion. They will be covered later In this section.) 
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Assume that the operator, in response to the ENTER PART NAME: 
prompt, enters BRACKETS, and then presses the ENTER key. The 
READTEXT at R1 will transfer the contents of the terminal buffer to 
the text buffer at T1. The READTEXT at R2 will then display the 
prompt message ENTER PART NBR: on the next line, and TERM 
will again be suspended, waiting for operator input. 

The operator then enters 105636, and presses ENTER again. The 
READTEXT at R2 transfers 105636 to the text buffer at T2, and the 
program runs to completion. 



TERM 


PROGRAM 


START 


lOCBl 


lOCB 


NHIST=0 


START 


ENQT 


lOCBl 


Rl 


READTEXT 


Tl, 'ENTER PART NAME 


R2 


READTEXT 

DEQT 

PROGSTOP 


T2,T3,PR0MPT-C0ND 


Tl 


TEXT 


LENGTH=20 


T2 


TEXT 


LENGTH=6 


T3 


TEXT 

ENDPROG 

END 


'ENTER PART NBR:' 



LINE=3 



Figure 11-20. READTEXT operation 

If the operator knows that the prompt ENTER PART NBR: will 
follow the first prompt of ENTER PART NAME:, he may make both 
the part name and part number entries on the same line (line 3), in 
response to the first prompt. The READTEXT at R2 has PROMPT= 
COND coded, meaning that the prompt message ENTER PART NBR: 
will be issued conditional on the absence of advance input in the 
previous operation. 

If the operator entered BRACKETS 105636 when the first prompt 
ENTER PART NAME: was displayed, the READTEXT at R2 would 
detect advance input, and would transfer the second part of the entry 
(the advance input, 105636) into the text buffer at T2, without 
issuing the prompt message ENTER PART NBR:, and without 
suspending TERM to wait for the ENTER key. 

The presence of advance input is indicated by an imbedded blank 
within an input character string. PROMPT=COND will, therefore, 
not work if the previous operation (the operation where advance 
input is expected) has MODE=LINE in effect, allowing imbedded 
blanks. In this case, the operation would not terminate when a 
blank in the input is found. 
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Since advance input {PROMPT=COND) can only be used when 
MODE=WORD is also used, care must be taken that no blanks, 
other than those separating entries, appear in the input string. 
For example, if the operator wished to use advance input, but 
mistakenly entered WALL BRACKETS 105636, the first input 
operation (READTEXT at R1) would terminate with the blank 
between WALL and BRACKETS, and WALL would be transferred 
to the text buffer T1. The READTEXT at R2, operating with ad- 
vance input because of the imbedded blank, would transfer BRACKE 
into text buffer T2, would not issue the prompt at T3, and would 
terminate due to exhaustion of the character count of 6 in the input 
buffer. The actual part number 105636 would never be read. 



OPERATOR CONTROL OF PROGRAM EXECUTION 



PF and Attention Key Handling 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "Terminal I/O - Attention 
Handling", "ATTN LIST", "ENDATTN." 

Attention routines are user routines that service interrupts generated 
by pressing the ATTENTION key on a terminal {re\i\e\N Attention 
Lists in Section 3). The ATTN LIST statement is used to define oper- 
ator entries and corresponding program locations that will receive 
control when the defined entries are made. 

The Program Function keys on 4978/4979/3101 M2 Displays generate 
interrupts similar to those generated by the ATTENTION key and the 
entry points of routines to service these PF interrupts may also be 
defined using the ATTN LIST statement. 

The ATTN LIST statement in Figure 1 1-21 defines three attention 
routine entry points. SET1, the first entry point, operates with the 
ATTENTION key. If an operator presses ATTENTION, enters 
the characters ONE, and then presses the ENTER key, location SET1 
receives control. 
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PROG 


PROGRAM 




ATTN LI ST 


START 


IF 




IF 




IF 



START 

(0NE,SET1,$PF1,P1,$PF,END) 
(SWITCH, EQ,1), GOTO, PRINT 
(SWITCH, EQ, 2), GOTO, PFPRINT 
(SWITCH, EQ, 3), GOTO, OUT 



BACK 


GOTO 


START 


PRINT 


MOVE 


SWITCH, 




PRINTEXT 


'ATTENTION INTERRUPT' 




PRINTEXT 


SKIP=1 




GOTO 


START 


PFPRINT 


MOVE 


SWITCH, 




PRINTEXT 


'PROGRAM FUNCTION KEY #1 




PRINTEXT 


SKIP=1 




GOTO 


START 


SETl 


MOVE 
ENDATTN 


SWITCH,! 


PI 


MOVE 
ENDATTN 


SWITCH, 2 


END 


MOVE 
ENDATTN 


SWITCH, 3 


OUT 


PROGSTOP 




SWITCH 


DATA 

ENDPROG 

END 


F'O' 



Figure 11-21. Attention routines 



Program Function keys are identified in an ATTN LI ST statement by 
the system convention "$PFx", where x is an integer between 1 and 
6, corresponding to Program Function keys PF1 through PF6. In this 
example, location PI will get control when PF1 Is pressed. (The 
X = integer between 1 and 6 applies to the 4979 Display. When using 
the 4978 Display, many more interrupting keys are available, and the 
PFx in an ATTN LIST statement may range between PF1 and PF254.) 
The 3101 M2 has 8 program function keys available. 

When $PF is used without a specific number, it is interpreted as all 
PF keys not previously defined (to the left of this entry) in this 
ATTNLIST statement. In Figure 11-21, Program Function key 1 Is 
previously defined (middle operand pair $PF1,P1), so location END 
will get control if PF2 through PF6 is pressed, and P1 will get control 
if PF1 is pressed. If the second and third operand pairs in the 
ATTNLIST statement were coded in reverse order, END would get 
control when any PF key was pressed, including PF1; control would 
never be transferred to PI. 

Attention routines execute as part of the system keyboard task, not 
as part of the user task within which they appear. Since user inter- 
ference with system keyboard task execution is clearly undesirable, 
certain I/O and task control instructions are not allowed within 
attention routines. See the reading assignment for a list of excluded 
instructions. 



11-20 SR30-0436 



QUESTION Instruction 



When the keyboard task detects an ATTENTION or PF key interrupt 
for a task with the appropriate entry points defined in an ATTN LIST 
statement, part of the response process is to briefly enqueue the 
interrupting terminal (ENQT). If the user task has an ENQT already 
in effect, the keyboard task is prevented from getting in. For an interrupt 
resulting from the operator's pressing the ATTN key, the system cannot 
present the > prompt character until the user program issues a DEQT, 
at which time the > will be displayed. For interrupts generated by 
depression of PF keys or the ENTER key (while the terminal is 
enqueued by the user), the system returns an identifying code to the user 
program. This code can be examined by user instructions to determine 
which key was pressed. All PF keys and the ENTER key will present 
identifying codes; the user is not restricted to those PF keys defined 
in an ATTN LIST statement whose function has been temporarily 
inhibited by a user ENQT. Examples later in this section will illustrate 
how to retrieve and use the identification codes resulting from PF 
key or ENTER key interrupts. 

Attention routines execute on hardware level 1, thereby automatically 
preempting execution of all user tasks on levels 2 and 3. They should, 
therefore, be kept very short and are usually limited to the setting 
of a program switch (or posting an ECB) which is checked during 
normal program execution. The example in Figure 1 1-21 illustrates 
this. 

This program checks a program indicator for a value, and branches 
to different program locations, depending on what value is found. 
In this case, the indicator is the word at location SWITCH, which 
has an initial value of zero. As long as SWITCH remains zero, the 
program will loop between START and BACK. 

Pressing the ATTENTION key and entering ONE results in execution 
of the attention routine at SET1, altering the value of SWITCH to = 1. 
When the IF statement at START is next executed, control will be 
transferred to PRINT, and the message ATTENTION INTERRUPT 
will be displayed. Pressing PF1 will set SWITCH=2 (attention 
routine at P1), and result in a transfer to PFPRINT, which will display 
PROGRAM FUNCTION KEY #1. Pressing any Program Function key 
other than PF1 will end the program (SWITCH=3, transfer to location 
OUT). Note that the attention routine at location END (PF2 through 
PF6) only sets location SWITCH to cause a later transfer to the 
PROGSTOP; PROGSTOP is one of the instructions excluded from 
attention routines, and cannot be issued from within the attention 
routine itself. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "QUESTION." 

The QUESTION statement provides another way of altering program 
execution through terminal input. QUESTION displays a prompt 
message, usually in the form of a question, and branches to a specified 
location based on the response entered on the terminal. 



Terminal I/O 11-21 



WAIT KEY Instruction 



label j QUESTION pmsgl YES=,NO=,SKIP=,LINE=,SPACES= 

OPTIONAL MUST BE CODED AT LEAST OPTIONAL 

ONE MUST 
BE CODED 



Figure 11-22. QUESTION format 

The pmsg operand is coded as the prompt message, contained within 
apostrophes, or as the label of a TEXT statement containing the 
prompt message. 

The YES= and N0= operands are coded with the labels of the program 
locations which are to get control if a YES or a NO response is 
entered. The only valid responses to a QUESTION prompt are Y and 
N (or any character string beginning with Y or N). Either YES= or 
N0= may be left uncoded, but not both. Entering the uncoded 
response will result in transfer to the instruction following the 
QUESTION statement. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "WAIT." 

In addition to the implied wait for operator input that is provided 
by the READTEXT and QUESTION instructions, the user can wait 
for the ENTER key or PF keys at any time, using a special variation 
of the WAIT statement, WAIT KEY. This instruction suspends the 
issuing task until the ENTER key or one of the PF keys is pressed, 
at which time the WAIT terminates, and execution continues with the 
instruction following the WAIT KEY. There is no automatic transfer 
to an attention routine; execution of a WAIT KEY instruction enqueues 
the terminal and temporarily inhibits the ATTN LIST capability during 
the time the task is suspended due to that WAIT instruction, just as the 
ATTN LIST function is inhibited while an ENQT is in effect. 

WAIT KEY is most often used by tasks operating terminals as static 
screen devices. In the roll screen examples shown before, issuing a 
READTEXT command caused a suspension of the Issuing task, waiting 
on operator input. Execution resumed, and the input operation com- 
pleted only when the operator signalled the program that the input data 
was available by pressing the ENTER key. 

When operating with static screens, the ENTER key signals that an 
entire page (screen) of input data Is available. READTEXT instructions 
directed to a static screen terminal therefore do not cause the issuing 
task to wait; the input data is expected to be present, and is transferred 
immediately. 

WAIT KEY allows a task with a terminal enqueued as a static screen 
device to wait on the ENTER key (or PF keys), even though the implied 
wait with READTEXT is not operative. 
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HARDCOPY PF Key 



Note: When operating with static screen devices, the implied wait with 
READTEXT is inoperative only when the READTEXT has no prompt 
message coded. Terminal input operations that are obviously intended 
for operator dialogue, such as a READTEXT with the pmsg operand 
coded, or a QUESTION instruction, still work the same as with roll 
screens, automatically suspending the issuing task. 

As already noted, the ATTN LIST capability is inhibited when a 
terminal is enqueued by a task as either a roll screen or static screen 
device, and/or when the task is suspended by a WAIT KEY instruction. 
Although automatic transfer to individual attention routine entry 
points associated with specific PF keys is no longer possible, the user 
can find out which key was pressed, and do the routing personally. 
An integer value equal to the numeric designation of the PF key is 
passed back to the user task in the second word of the task's TCB 
(taskname+2), and may be examined by the user program. The code 
passed back for the ENTER key is zero. For PF1, taskname+2 
will contain a 1, for PF2 a 2, and so on through 6 for PF6. The code 
can be checked, and a transfer decision made, using IF statements or 
a computed GOTO. 

{Note: When using the 4978 Display, many more interrupting keys and 
corresponding identification codes are available than with the 4979 
terminal discussed above. See the topic "$PFMAP" in Section 14. 
Utility Programs for an aid in determining the identification codes 
associated with particular 4978 interrupting keys.) 



One of the operands in the TERMINAL statement defining 4978/4979 
Displays is HDCOPY=. This is coded with the symbolic name of a 
hardcopy terminal and a PF key number, in the format HDCOPY= 
(termname,keynbr). The termname must be coded. If keynbr is not 
coded, it defaults to 6, indicating Program Function key PF6. 

Whenever the PF key specified in the HDCOPY= operand is depressed, 
the present screen contents are printed out on the designated hardcopy 
device. The default for the 4979 supported by the supplied supervisor 
is HDC0PY=($SYSPRTR,6), causing the screen contents to be printed 
on the 4974 Matrix Printer whenever PF6 is depressed. 

Not knowing which PF key you may designate to activate the 
hardcopy system function, all examples in this section address Program 
Function keys PFl through PF6 (as though HDCOPY= were coded 
HDC0PY=($SYSPRTR,6)). 

In coding your own programs, you should be aware that the key you 
specify in the HDCOPY= operand is not available to you for other 
purposes. If specified in an ATTN LIST statement, the associated 
entry point will never receive control nor will pressing the hardcopy 
PF key terminate a WAIT KEY operation, or present its code in 
taskname+2. 
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STATIC SCREEN CODING EXAMPLE 



In the following several illustrations (Figures 11 -23 through 11-43), 
a simple static screen progrann is developed, using most of the terminal 
instructions already discussed, and introducing some new instructions 
applicable only to static screen operation. 

The initial portion of this program operates the terminal as a roll 
screen device, with NHIST=0. The rest of the program uses the 
terminal in the static screen mode. An lOCB will be required for 
each of the two modes. 

Operator instructions are displayed requiring the operator to (1) end 
the program, or (2) bring up the entry screen (static screen) and proceed. 
The operator's decision is communicated to the program using the 
ATTN LIST facility, so an ATTN LIST statement will also be required. 

Figure 1 1-23 shows the two lOCBs, the ATTNLIST statement, and 
the associated attention routines. 



XMPLSTAT PROGRAM 
lOCBl lOCB 
I0CB2 lOCB 

ATTNLIST 



START 

NHIST=0 

SCREEN=STATIC 

(END, OUT, $PF, STATIC) 



OUT 


POST 
ENDATTN 


ATTNECB,! 


STATIC 


POST 
ENDATTN 


ATTNECB,-! 


ATTNECB 


ECB 





ENDPROG 
END 

Figure 11-23. lOCB/ATTNLIST 



Figure 1 1-24 is the entire roll screen portion of the program. Execution 
begins at location START, with the ENQT directed to I0CB1. The 
lOCB changes NHIST=1 2 to NHIST=Ofor the loading terminal (no 
terminal name specified in the lOCB, default to loading terminal, and 
assuming loading terminal is a 4979 with NHIST=12 normally in 
effect). 

Now that the loading terminal is enqueued, the five PRINTEXT 
statements following the ENQT display the program title and 
operator directions on the screen. Since operator control has been 
defined through an ATTNLIST, and ATTNLIST is inhibited while 
the terminal is enqueued, the last PRINTEXT is followed by a DEQT, 
placing the ATTNLIST in effect. 
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XMPLSTAT PROGRAM START 

lOCBl lOCB NHIST=0 

I0CB2 lOCB SCREEN=STATIC 

ATTNLIST (END, OUT, $PF, STATIC) 

START ENQT lOCBl 

PRINTEXT 'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

PRINTEXT 'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

PRINTEXT ' THE PROGRAM' 

PRINTEXT 'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

PRINTEXT ' BRING UP THE ENTRY SCREEN' 

DEQT 

CHECK WAIT ATTNECB, RESET 

IF ( ATTNECB, EQ,1), GOTO, ENDIT 

ENTRY ENQT I0CB2 



ENDIT 



PROGSTOP 



OUT POST ATTNECB,! 

ENDATTN 
STATIC POST ATTNECB,-! 

ENDATTN 
ATTNECB ECB 



ENDPROG 
END 

Figure 11-24. Roll screen portion 

The ECB at location ATTNECB assembles with an initial value in the 
first word of -1 indicating "event complete". The WAIT at location 
CHECK is coded with a RESET operand, which resets the first word 
of the ECB at ATTNECB to zero before the WAIT is executed. A zero 
in the first word of an ECB indicates "event not occurred," so the 
WAIT at CHECK will suspend task XMPLSTAT, waiting on event 
ATTNECB. If the WAIT has been coded without the RESET operand, 
the WAIT would have executed as a no-op. 

If the operator presses ATTENTION, enters END and presses 
RETURN, the attention routine at OUT will execute, posting the 
ECB at ATTNECB with a +1 (first word = 1). A value other than 
zero in the first word of the ECB indicates "event complete," and 
the WAIT operation terminates. Execution continues with the I F 
statement following the WAIT, which will transfer control to location 
ENDIT. 



TerminaM/O 11-25 



If the operator wants to proceed with the CLASS ROSTER PROGRAM 
and presses a PF key, ATTNECB will be posted with a value of -1 by 
the attention routine at STATIC. The WAIT will terminate, the IF 
that follows will not transfer control to ENDIT (ATTNEBC N0T = +1), 
and execution will continue with the ENQT at location ENTRY, which 
is the beginning of the static screen portion of the program. 

After the program title and operator instructions have been written 
to the terminal (while the program is waiting at CHECK for the 
operator response), the screen looks like Figure 1 1-25. 
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Figure 11-25. Initial operator instructions 

Assuming the operator pressed a PF key, execution now continues 
at location ENTRY (Figure 1 1-26). The ENQT enqueues the terminal 
as a static screen device. 



V. 



ERASE instruction 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "ERASE." 

An automatic erase of a roll screen is performed by the system each 
time the page size of the screen is exceeded. Erasure of a static screen 
device is a user responsibility, and the ERASE instruction is, 
therefore, valid only for static screens. 

You can select how much you want to erase, from as little as a single 
character position to the entire screen. In Figure 11-26, the ERASE 
following the ENQT will erase the entire screen. The MODE= operand 
defines the ending point of the erase operation; in this case, the end of 
the screen. The starting point of the erase is determined by SKIP=, 
LINE=, and SPACES= forms operands, in this example defaulting to 
LINE=0, SPACES=0. TYPE= specifies whether only unprotected 
data should be erased (TYPE=DATA) or if the erase applies to 
protected data also (TYPE=ALL). 
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XMPLSTAT PROGRAM 
lOCBl lOCB 
I0CB2 lOCB 

ATTNLIST 
-^:c4ax____EN0L 
ChrE"CTr 

IF 
ENTRY ENQT 
ERASE 
TERMCTRL 
PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 



START 

NHIST=0 

SCREEN=STATI 



, RESET 

(ATTNECB,EQ,1),G0T0,ENDIT 
I0CB2 

MODE=SCREEN,TYPE=ALL 
BLANK 
ENTER KEY = PAGE C0MPLETEMINE=1 
PFl = DELETE ENTRY 1" 
PF2 = DELETE ENTRY 2' 
PF3 = DELETE ENTRY 3 ' ,SKIP=1 
PF4 = DELETE ENTRY 4' 



ENDPROG 
END 

Figure 11-26. Operator directions 



TERMCTRL Instruction 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "TERMCTRL." 

TERMCTRL is used for several specialized functions, most of which are 
device/hardware feature dependent control operations. The 3101 
operating in block mode uses an attribute byte (prefixed to the data 
field) to define the display mode as low or high intensity, blinking or 
non-display. The TERMCTRL statement is used to set the character- 
istics of the attribute byte. In Figure 11-26, the TERMCTRL BLANK 
instruction blanks the 4979 display screen. 

The remainder of this portion of the program is going to format the 
display screen by executing a series of PRINTEXT instructions. When 
several operations are performed sequentially, the 4979 screen exhibits 
a flickering that some people find annoying. Issuing the TERMCTRL 
BLANK turns off the display capability of the screen, allowing the 
series of output operations to take place without visible flicker. After 
the formatting has been completed, another TERMCTRL function will 
be used to display the finished screen. 

The five PRINTEXT instructions following the TERMCTRL will write 
some operator guides at the top of the screen. When these instructions 
have executed, the screen would look like Figure 1 1-27 (assuming an 
unblanked screen). 



Terminal I/O 11-27 



LINES 

t 


1 
2 

3 
4 
5 
6 
7 
8 



ENTER KEY = PAGE COMPLETE 
PF3 = DELETE ENTRY 3 



PFl 
PF4 



DELETE ENTRY 
DELETE ENTRY 



PF2 = DELETE ENTRY 2 



CHARACTER 
POSITIONS — 



11111111 1 12222222222333333333344444444445555555555666666666677777777778 
-12345678901234567890123456789012345678901234567890123456789012345678901234567890 



Figure 11-27. Operator directions/screen 

In Figure 1 1-28, execution continues with the PRINTEXT at location 
HDR. This Instruction writes a screen-wide (80 character) line of 
hyphens, separating the operator guide area just written from the 
rest of the screen. The text buffer referenced by this Instruction 
(location DASHES) is not the label of a TEXT statement, but is a 
user-defined text buffer. Since PRINTEXT uses the control bytes 
that precede text buffers generated by TEXT statements, the user 
must code the control bytes when defining non-TEXT statement 
text buffers. 

The DATA statement preceding location DASHES is coded as 
X'5050', establishing a length byte of 80 and a count byte of 80 
(hex 50=declmal 80). This tells the PRINTEXT at HDR that the 
buffer is 80 character positions long, and that all 80 positions 
contain data. 
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XMPLSTAT 

lOCBl 

JL0CB2 




HDR 



PROGRAM 
lOCB 
lOCB 
AT TNLIST 

PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 
MOVE 



START 

NHIST=0 

SCREBJ^ 

PF2 
'PF3 = DELETE 
'PF4 = DELETE 




,SKIP=1 



mGE COMPLETE' 
= DELETE ENTRY 1' 
= DELETE ENTRY 2' 
ENTRY 3 
ENTRY 4' 
DASHES, PR0TECT=YES,LINE=3 
■CLASS NAME:',LINE=4,PR0TECT=YES 
'INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 
DASHES, PR0TECT=YES,LINE=5 
LINENBR,6 



DASHES 



DATA 
DATA 



X'5050 
80C'-' 



ENDPROG 
END 

Figure 11-28. Non-standard text buffer 



The PROTECT=YES operand specifies that the line of hyphens be 
written as protected data. Protected data cannot be altered by 
operator input. 

The next PRINTEXT places CLASS NAME: in the first eleven 
positions of line 4, and the following one puts INSTRUCTOR NAME: 
on the same line, with both messages protected. 

The last PRINTEXT in Figure 1 1-28 writes another separator line 
of hyphens, again using the user-defined text buffer at DASHES. 
Figure 1 1-29 shows how the screen would look if it were displayed 
at this point. 
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Figure 11-29. Header 



The rest of the screen formatting section of the program Is shown In 
Figure 1 1-30. This portion will format the remainder of the screen 
Into four data entry areas. 

First, the variable LINENBR is set to 6. Next, a DO loop is defined, 
specifying four executions of the loop, corresponding to the four 
data entry areas to be formatted. 

All PRINTEXT instructions within the loop have the LINE= operand 
coded, with the variable name LINENBR, rather than as an integer 
constant. Before this first execution of the DO loop, LINENBR 
was initialized to 6. The first PRINTEXT writes the protected 
characters NAME: Into the first 5 positions of line 6, and the second 
PRINTEXT leaves 25 unprotected spaces following NAME:, and 
writes STREET: to the same line. 
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XMPLSTAT PROGRAM 
lOCBl lOCB 




HDR 



PRINTEXT 

PRINTEXT 

PRINTEXT 

MOVE 

DO 

PRINTEXT 

PRINTEXT 

Al ADD 

PRINTEXT 

A2 ADD 

PRINTEXT 

ADD 

ENDDO 

PRINTEXT 

TERMCTRL 

WAITONE WAIT 




START 

NHIST=0 

SCREEN=3: 

rrToHES,PR0TECT=YES,LINE=3 

•CLASS NAME: ' ,LINE=4,PR0TECT=YES 

' INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 

DASHES, PR0TECT=YES,LINE=5 

LINENBR,6 

4, TIMES 

'NAME: ' ,LINE=LINENBR,PROTECT=YES 

'STREET: ■,LINE=LINENBR,SPACES=30,PR0TECT=YES 

LINENBR,! 

'CITY : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 

LINENBR, 1 

•STATE : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 

LINENBR, 3 

LINE=4,SPACES=11 

DISPLAY 

KEY 



LINENBR 



DATA 

ENDPROG 

END 



F'O 



Figure 1 1-30. Finish formatting the screen 



Next, the ADD at Al Increases LINENBR by 1, and the PRINTEXT 
that follows Is directed to line 7, LINENBR Is again Incremented 
(ADD at A2), and the last PRINTEXT Is directed to line 8. The 
ADD just preceding the ENDDO Increases LINENBR by 3, skipping 
down to the next data entry area to be formatted. 

After four executions of the DO loop, the PRINTEXT Immediately 
following the ENDDO statement Is executed. This PRINTEXT 
positions the cursor just to the right of the CLASS NAME: message 
in the screen header, above the four data entry areas just formatted 
in the DO loop. The TERMCTRL DISPLAY command removes 
the blanking from the screen, and displays the cursor at the position 
determined by the previous PRINTEXT. Figure 1 1-31 shows the 
fully formatted screen that Is now displayed. 
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Figure 1 1-31 . Completed format 



The program is in a wait state, suspended by execution of the 
WAIT KEY at location WAITONE. The program will not be 
activated again until the operator presses the ENTER key or one of 
the PF keys. 

The screen is now completely formatted, and ready for data entry. 
Figure 1 1-32 shows the complete screen formatting portion of the 
program. 



V ^ 
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XMPLSTAT PROGRAM 
lOCBl lOCB 
I0CB2 IOCS 



START 

NHIST=0 

SCREEN=STATIC 



ENTRY ENQT 
ERASE 
TERMCTRL 
PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 

HDR PRINTEXT 
PRINTEXT 
PRINTEXT 
PRINTEXT 
MOVE 
DO 

PRINTEXT 
PRINTEXT 

Al ADD 

PRINTEXT 

A2 ADD 

PRINTEXT 

ADD 

ENDDO 

PRINTEXT 

TERMCTRL 

WAITONE WAIT 



I0CB2 

MODE=SCREEN,TYPE=ALL 

BLANK 

'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PFl = DELETE ENTRY 1' 

PF2 = DELETE ENTRY 2' 
'PF3 = DELETE ENTRY 3 ' ,SKIP=1 
'PF4 = DELETE ENTRY 4' 
DASHES, PR0TECT=YES,LINE=3 
'CLASS NAME: ' ,LINE=4,PR0TECT=YES 
'INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 
DASHES, PR0TECT=YES,LINE=5 
LINENBR,6 
4, TIMES 

'NAME: ' ,LINE=LINENBR,PROTECT=YES 
'STREET: ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 
LINENBR,1 

'CITY : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 
LINENBR,1 

'STATE :',LINE=LINENBR,SPACES=30,PR0TECT=YES 
LINENBR,3 

LINE=4,SPACES=11 

DISPLAY 

KEY 



DASHES 



DATA 
DATA 



X'5050' 
80C'-' 



LINENBR 



DATA 

ENDPROG 

END 



F'O 



Figure 11-32. Screen formatting section 



The operator may position the cursor at will, and enter data in any 
unprotected area of the screen. Positioning the cursor at LINE=4, 
SPACES=1 1 (PRINTEXT following ENDDO), is a convenience to 
the operator, not a required function — the operator could have used 
the cursor positioning keys to move the cursor to the same position. 
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Some cursor-positioning functions are automatically provided by the 
hardware. Assume that the operator enters SERIES/1 HARDWARE 
in the space immediately following the protected CLASS NAME: 



message, and then presses the tab right key 



). The cursor 



will automatically skip over the protected INSTRUCTOR NAME: 
field, and position itself at the beginning of the unprotected area 
which follows, as shown in Figure 1 1-33. 
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Figure 11-33. Cursor movement (1) 



After entering the instructor name, the next tab right key depression 
results in the cursor position shown in Figure 1 1-34, ready for the 
first student name entry. 
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Figure 11-34. Cursor movement (2) 
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Each successive tab key depression results in an automatic skip 
of the cursor to the beginning of the next unprotected area on the 
screen. In this example, the cursor will successively tab to NAME:, 
STREET:, CITY:, and STATE:, and then down to the NAME: in 
the next data entry area, as shown in Figure 1 1-35. 
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Figure 11-35. Cursor movement (3) 

With no interaction with the program, an entire screen of information 
can be prepared for input, and transferred at one time. This is what 
is meant by static screen operation, in contrast to the transactional 
prompt/reply dialogue typical of roll screen operation. 

Figure 1 1-36 shows a completed input screen. The operator Is 
now at the point where the program must be signalled to proceed. 
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Figure 11-36. Fullscreen 
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In Figure 1 1-37, the WAIT KEY at WAITONE will be terminated 
by pressing the ENTER key or a PF key. The computed GOTO 
following the WAIT KEY will transfer control to various entry 
points, depending on the return code in "taskname+2." A return 
code of zero, from the ENTER key, will cause a transfer to location 
READ. PF1 through PF4 will return codes of 1 through 4, and result 
in transfers to El through E4, respectively. (With the GOTO coded 
as shown, a PF key higher than PF4 will cause a transfer to READ, 
as the return code would be outside the valid range of index values 
1-4, just as the zero returned by the ENTER key is outside that range, 
and also results in a transfer to READ.) 

For now, assume the operator presses the ENTER key, signalling 
the program that the page is complete, and transferring control to 
READ. 
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PRINTEXT 

TERMCTRL 

GOTO 
CLEANUP ERASE 

DEQT 

GOTO START 



'MORE ENTRIES ?' ,LINE=2,SPACES=55,N0=CLEANUP 

M0DE=LINE,LINE=2,SPACES=55,TYPE=DATA 

M0DE=SCREEN,LINE=6 

LINE=6,SPACES=5 

DISPLAY 

WAITONE 

MODE=SCREEN,TYPE=ALL 



ENDPROG 
END 

Figure 11-37. ENTER key 



In a real program, the routine at location READ would contain the 
READTEXT instructions necessary to read all the data entered on 
the screen. In the application illustrated here, that data would 
presumably be collected and used to print a class roster for the 
SERIES/1 HARDWARE course taught by JOHN JONES. 

Assuming that the contents of the screen has been transferred, the 
QUESTION instruction at READ displays the prompt message 
MORE ENTRIES? in the operator guide area at the upper right of 
the screen, as shown in Figure 1 1-38. 
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LINES 

\ 


1 
2 

3 
4 
5 
6 
7 
8 

g 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 

CHARACTER 
POSITIONS — 



r 


> 


ENTER KEY = PAGE COMPLETE 
PF3 = DELETE ENTRY 3 


PFl = DELETE ENTRY 1 PF2 = DELETE ENTRY 2 
PF4 = DELETE ENTRY 4 MORE ENTRIES ? _ 


CLASS HAME: SERIES/ 1 HARDWARE 


INSTHUCIOR NAMl': JOHN JONES 


NAME: JOHN JAMES 


SiKi:i:".T: 111 GRANT AVENUE 
CnV ; ENDICOTT 
STATL : NEW YORK 13760 


NAME; JAMES JONES 


STRCLi: 255 ALHAHBRA CIRCLE 
CITV ; CORAL GABLES 
STAih : FLORIDA 33135 


NAMl: JIM JOHNS 


STIuILT: 140 EAST TOWN STREET 
CITY : COLUMBUS 
SlATf. : OHIO 43215 


uAME: JOAN JIMSON 
V — 


STKLLI: 6216 WASHINGTON AVENUE 

CITY : RACINE 

STATE : WISCONSIN 53406 



11111111 1 12222222222333333333344444444445555555555666666666677777777778 
■12345678901234567890123456789012345678901234567890123456789012345678901234567890 



Figure 11-38. After ENTER key 

The MORE ENTRIES? query is asking the operator, "Are there 
more students to add to this roster, or are the students just read from 
the current screen the last ones at this time?" 

The QUESTION statement is coded with NO=CLEANUP. YES= 
is not coded, and therefore a YES response will result in execution of 
the ERASE instruction following the QUESTION. Assume there are 
more students, and YES is the response. The first ERASE following 
the QUESTION clears the prompt and reply from the operator guide 
area, and the second ERASE clears all unprotected data from the 
four data entry areas in lines 6 through 23. The SERIES/1 
HARDWARE and JOHN JONES entries in the header area are left 
undisturbed, since the student names and addresses to be entered are 
still for the same class. 

The PRINTEXT following the second ERASE (Figure 11-37) positions 
the cursor at the first unprotected entry field for the first data entry 
area. The TERMCTRL DISPLAY that follows displays the cursor, 
resulting in the screen shown in Figure 1 1-39. 
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2 
3 

4 
5 
6 

7 
8 

g 

10 

11 

12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 

CHARACTER 
POSITIONS — 



ENTER 
PF3 = 


KEY = PAGE COMPLETE 
DELETE ENTRY 3 


PFl = DELETE ENTRY 1 PF2 = 
PF4 = DELETE ENTRY 4 


DELETE ENTRY 2 


Cl.AS; 


NAME5ERIES/1 


HARDWARE 


INSTRUCTOR NAME JOHN JONES 




NAME : 


— 




STREET: 
CITY : 
STATE : 




riAME: 






STREET: 
CITY : 
STATE : 




NAME : 






STREET: 
CITY : 
STATE : 




NAME : 






STREET: 
CITY : 
STATE : 


J 
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Figure 1 1-39. Reply YES to QUESTION 



If there were no more students to enter for this roster, and the 
response to the MORE ENTRIES? prompt were NO, the 
QUESTION statement (Figure 1 1-37) would transfer control to 
location CLEANUP, which erases both protected and unprotected 
areas of the entire screen, dequeues the terminal, and goes back to 
the beginning of the program (START), bringing up the roll screen 
with the initial operator directions, as shown in Figure 1 1-40. 



LINES 

♦ 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

CHARACTER 
POSITIONS — 



CLASS ROSTER PROGRAM 
HIT 'ATTN' AND ENTER 'END' TO END THE PROGRAM 
HIT ANY PROGRAM FUNCTION KEY TO BRING UP THE ENTRY SCREEN 
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Figure 1 1-40. Reply NO to QUESTION 
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In Figure 1 1-41, assume the program is again suspended by the WAIT 
KEY at WAITONE, with the completed screen depicted in Figure 1 1-36. 
The transfer to location READ and the MORE ENTRIES? prompt from 
the QUESTION statement resulted from the operator's pressing the 
ENTER key. The WAIT KEY may also be terminated by a PF key. 

There are no pre-assigned functions for PF keys, other than the 
hardcopy facility already discussed. Therefore, the purpose of a 
particular PF key in any program is defined by the instructions coded 
in the routine to which control Is transferred when that PF key is 
depressed. 

In the example in Figure 11-41, PF1 through PF4 have been assigned 
as delete functions for the four data entry areas, as shown by the 
operator guides at the top of the screen (Figure 11-36). 



XMPLSTAT 


PROGRAM 


START 


lOCBl 


lOCB 
lOCB 
ATTNLIST 


NHIST=0 


T0CB2 


c;rpEEN=STA"ri^^ - 




[jim.j'^;;;^:^^^^^^ 


^^"^^---^ 


~~=iiQT 


;^^;::::;i:<rspACEs=ii 




TLki^ilikl 


DISPLAY 


WAITONE 


WAIT 


KEY 




GOTO 


(READ,El,E2,E3,E4),XMPLSTAT+2 


El 


MOVE 


LINENBR,6 




GOTO 


DELETE 


E2 


MOVE 


LINENBR,11 




GOTO 


DELETE 


E3 


MOVE 


LINENBR,16 




GOTO 


DELETE 


E4 


MOVE 


LINENBR,21 


DELETE 


ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




ADD 


LINENBR,! 




ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




ADD 


LINENBR,: 




ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




SUBTRACT 


LINENBR, 2 




PRINTEXT 


LINE=LINENBR,SPACES=5 




TERMCTRL 


DISPLAY 




GOTO 


WAITONE 



LINENBR 



DATA 

ENDPROG 

END 



F'O 



Figure 11-41. PF keys 
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Assume that for some reason, the student JIM JOHNS, the third entry 
on the screen, is not supposed to be on the class roster; the operator, 
therefore, presses PF3. 

In Figure 1 1-41, the PF key terminates the WAIT KEY, and the 
computed GOTO transfers control to E3. The MOVE at E3 initializes 
the LINENBR variable to 16, which is the top line of the third data 
entry area. Control is then transferred to DELETE, where successive 
ERASE operations and adjustments of the LINENBR variable result 
in erasure of the unprotected portions of the third data entry area. 
Before returning to the WAIT KEY, the cursor is positioned and dis- 
played at the first entry field of the erased data area, as shown in 
Figure 11-42. 



LINES 

+ 


1 
2 
3 
4 
5 
6 
7 



'■ 




- 


ENTER KEY = PAGE COMPLETE 
PF3 = DELETE ENTRY 3 


PFl = 
PF4 = 


DELETE ENTRY 1 PF2 = DELETE ENTRY 2 
DELETE ENTRY 4 


CLASS NAME: SERIES/1 HARDWARE 


INSTRUCTOR NAME: jqhN JONES 


NAHr; jqhn JAMES 


STREET 

CITY 

SlAiE 


111 GRANT AVENUE 

ENDICOTT 

NEW YORK 13760 


iiAME: JAMES JONES 


STREET 

CITY 

STATE! 


255 ALHAMBRA CIRCLE 
CORAL GABLES 
FLORIDA 33135 


NAMt; : 


SfREET 

CITY 

STATE 




NAM!":: JOAN JIMSON 
I. 


STREET 

CITY 

STATE 


6216 WASHINGTON AVENUE 

RACINE 

WISCONSIN 53406 



CHARACTER 
POSITIONS — 
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Figure 11-42. After PF3 

For your reference, the program example used in the foregoing dis- 
cussion is shown in its entirety in Figure 1 1-43. 
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XMPLSTAT 

lOCBl 

I0CB2 

START 



CHECK 
ENTRY 



PROGRAM START 

lOCB NHIST=0 

lOCB SCREEN=STATIC 

ATTNLIST (END, OUT, $PF, STATIC) 



ENQT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

DEQT 

WAIT 

IF 

ENQT 

ERASE 



lOCBl 

CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 
HIT "ATTN" AND ENTER "END" TO END' ,SKIP=2 

THE PROGRAM' 
HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

BRING UP THE ENTRY SCREEN' 



ATTNECB, RESET 
(ATTNECB,EQ,1),G0T0,ENDIT 
I0CB2 
MODE=SCREEN,TYPE=ALL 

TERMCTRL BLANK 

PRINTEXT 'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PRINTEXT ' PFl = DELETE ENTRY 1' 

PRINTEXT ' PF2 = DELETE ENTRY 2' 

PRINTEXT 'PF3 = DELETE ENTRY 3 ',SKIP=1 

PRINTEXT 'PF4 = DELETE ENTRY 4' 

HDR PRINTEXT DASHES, PR0TECT=YES,LINE=3 

PRINTEXT 'CLASS NAME: ' ,LINE=4,PR0TECT=YES 

PRINTEXT ' INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 

PRINTEXT DASHES, PR0TECT=YES,LINE=5 

MOVE LINENBR,6 

DO 4, TIMES 

PRINTEXT 'NAME: ' ,LINE=LINENBR, PROTECT-YES 

PRINTEXT 'STREET: ',LINE=LINENBR,SPACES=30,PR0TECT=YES 

Al ADD LINENBR,! 

PRINTEXT 'CITY : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 

A2 ADD LINENBR,! 

PRINTEXT 'STATE : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 

ADD LINENBR, 3 

ENDDO 

PRINTEXT LINE=4,SPACES=11 

TERMCTRL DISPLAY 

WAITONE WAIT KEY 

GOTO (READ,El,E2,E3,E4),XMPLSTAT+2 

Figure 11-43. Complete program (1 of 2) 
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El 


MOVE 


LINENBR, 6 




GOTO 


DELETE 


E2 


MOVE 


LINENBR, 11 




GOTO 


DELETE 


E3 


MOVE 


LINENBR, 16 




GOTO 


DELETE 


E4 


MOVE 


LINENBR, 21 


DELETE 


ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




ADD 


LINENBR, 1 




ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




ADD 


LINENBR, 1 




ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




SUBTRACT 


LINENBR, 2 




PRINTEXT 


LINE=LINENBR,SPACES=5 




TERMCTRL 


DISPLAY 




GOTO 


WAITONE 


READ 


QUESTION 


'MORE ENTRIES ? ' ,LINE=2,SPACES=55,N0=CLEANUP 




ERASE 


M0DE=LINE,LINE=2,SPACES=55,TYPE=DATA 




ERASE 


M0DE=SCREEN,LINE=6 




PRINTEXT 


LINE=6,SPACES=5 




TERMCTRL 


DISPLAY 




GOTO 


WAITONE 


CLEANUP 


ERASE 
DEQT 


MODE=SCREEN,TYPE=ALL 




GOTO START 


ENDIT 


PROGSTOP 






DATA 


X'5050' 


DASHES 


DATA 


80C'-' 


OUT 


POST 
ENDATTN 


ATTNECB, 1 


STATIC 


POST 
ENDATTN 


ATTNECB, -1 


ATTNECB 


ECB 




LINENBR 


DATA 

ENDPROG 

END 


F'O' 



Figure 11 -43. Complete program (2 of 2) 
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RDCURSOR INSTRUCTION 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "RDCURSOR." 

Another instruction applying only to static screens, but not used in 
the foregoing programming example, is RDCURSOR. This Instruction 
will store the line number and indent from the left margin (SPACES) 
corresponding to the current cursor position. In user program variables. 
It can be used as an additional means of communication between 
program and operator. For example, if a prompt displayed on a 
particular screen is unusually cryptic, an operator unfamiliar with the 
application might not know what data should be entered in the associ- 
ated data entry field. If a particular PF key is designated as the 
help function, and results in a transfer to a routine which executes 
a RDCURSOR instruction, the operator can position the cursor in 
the data entry field whose purpose is in doubt, and press the help 
PF key. The RDCURSOR command could then sense the cursor 
position, find out which field is causing the confusion by comparing 
the sensed position to the known data entry field locations, and 
display explicit instructions for the field in question. 

PRINTNUM/GETVALUE INSTRUCTIONS 

READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "PRINTNUM", "GETVALUE." 

The PRINTEXT and READTEXT instructions are used to transfer 
^ EBCDIC character strings to and from terminals. PRINTNUM 

and GETVALUE instructions perform the same functions for 
numeric values. PRINTNUM takes a numeric value in storage, 
automatically performs the conversion from internal (binary) 
representation, and transfers it to a terminal for display or 
printing. 
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PRINTNUM can display a single value, 



PRINTNUM loc 



pi PROGRAM START 

START PRINTEXT 'VALUE = 

PRINTNUM IVAL 

PRINTEXT SKIP=1 
PROGSTOP ^^^^, 

IVAL DATA F' 31416 
ENDPROG 
END 
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— or a single PRINTNUM statement can be used to display multiple 
values. When more than one value is displayed by the same 
PRINTNUM, the values can be displayed on separate lines. 



PRINTNUM loc, count, nline 



PI 


PROGRAM 


START 


START 


PRINTEXT 


'VALUES' 




PRINTNUM 


IVALS,3,1,SKIP=1 




PRINTEXT 


SKIP=1 




PROGSTOP 




IVALS 


DATA 


F'31416' 




DATA 


F'500' 




DATA 


F'17' 




ENDPROG 






END 
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— or can 



be displayed on the same line. 



PRINTNUM loc^counWn^ 



PI PROGRAM START 

START PRINTEXT 'VALUES 

PRINTNUM 1VALS,3,3,SK1P i 

PRINTEXT SK1P=1 

PROGSTOP ■ ,^^.,.. 

IVALS DATA F; 31416 

DATA F 500 

DATA F 1/ 
ENDPROG 
END 
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When multiple values appear on the same line, you can control the 
spacing between values. 



PRINTNUM loc, count, nl ine,nspace 



PI PROGRAM START 

START PRINTEXT 'VALUES = ' 

PRINTNUM IVALS,3,3,10 

PRINTEXT SKIP=1 

PROGSTOP 

IVALS DATA F' 31416' 

DATA F'500' 

DATA F ' 17 ' 

ENDPROG 

END 
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If desired, values may be displayed in hexadecimal rather than 
decimal form. 



PRINTNUM 1 oc, count, nline, space, MODE= 



PI PROGRAM START 

START PRINTEXT 'VALUES = ' 

PRINTNUM IVALS,3,3,10,M0DE=HEX 

PRINTEXT SKIP=1 

PROGSTOP 

IVALS DATA F'31416' 

DATA F'500' 

DATA F'17' 

ENDPROG 

END 
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GETVALUE transfers a numeric text string, input by an operator, 

into storage, automatically converting to internal (binary) representation. 



GETVALUE loc 



PI 


PROGRAM 


STAR 


START 


GETVALUE 
PROGSTOP 


IVAL 


IVAL 


DATA 

ENDPROG 

END 


F'O' 
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As with READTEXT, a prompt message may be issued prior to the 
input operation. 



GETVALUE locpmsg 



PI PROGRAM START 

START GETVALUE IVAL, ' ENTER VALUE: ' 

PROGSTOP 
IVAL DATA F'O' 

ENDPROG 

END 
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Multiple values can be read by a single GETVALUE instruction, 



GETVALUE locpmsg, count 



PI PROGRAM START 

START GETVALUE IVALS,' ENTER VALUES: ',3 

PROGSTOP 
IVALS DATA 3F'0' 

ENDPROG 

END 
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— and hexadecimal input can be accepted. 



GETVALUE locpmsg, count, MODE= 



PI PROGRAM START 

START GETVALUE IVALS, 'ENTER VALUES: ' ,3, MODE=HEX 

PROGSTOP 
IVALS DATA 3F'0' 

ENDPROG 

END 




Forms control operands (SKIP=, LINE=, and SPACES=) serve the 
same purpose and are used the same way with PRINTNUM and 
GETVALUE as for PRINTEXT and READTEXT. See the reading 
assignment for how to use PRINTNUM and GETVALUE with 
double precision integers, standard and extended precision floating 
point values, and the external data formatting option. 



PRINTIME/PRINDATE INSTRUCTIONS 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "PRINTIME", "PRINDATE." 

PRINTIME and PRINDATE are pre-defined terminal output 
operations. PRINTIME will display the current value of the system 
24 hour clock in the format HH:MM:SS. PRINDATE displays the 
date as MM/DD/YY or DD/MM/YY depending on the option selected 
on the SYSTEM statement when the supervisor was generated. 
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TERMINAL I/O REVIEW EXERCISE - QUESTIONS 

, J 1. Describe the program states or conditions wiiich, while in 

^-^ effect, inhibit the ATTN LIST capability. 



List three buffer forcing conditions. 

a. 



3. Assume the following two instructions are executed, directed at 
a static screen. 

PRINTEXT 'ENTER: ' ,LINE=3,PR0TECT=YES 

PRINTEXT 'NEXT ENTRY: ' ,SPACES=10,PR0TECT=YES 

What character position will the N in NEXT occupy? 

Answer: 

4. On the left are listed the interrupt generating terminal keys. 
In the space following each key, list the letter(s) designating 
the statement(s) on the right that apply to each key. More 
than one statement may be true for each key, and each state- 
ment may apply to more than one key. 

a. will terminate a WAIT KEY operation 

pp ^„„^ b. used with ATTN LIST, not with WAIT 

PF keys i^^Y 

ATTN key 



c. used with WAIT KEY, never with 
ENTER key ATTN LIST 

d. will not terminate a WAIT KEY operation 

e. can be used with ATTN LIST, and will 
also terminate a WAIT KEY 

5. List the special system terminals that may be enqueued by 
coding their names as the operand of an ENQT instruction. 

Answer: 
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Below on the left is a list of five operator entries. Each entry is in 
response to the GETVALUE prompt in the program given. 

On the right are spaces for the values that would be displayed 
by execution of the PRINTNUM immediately following the 
GETVALUE in the program. Fill in what the PRINTNUM 
would display after each of the entries on the left (each operator 
entry/PRINTNUM display pair should be considered a new load/ 
execution of the program). 



PI 
START 



VAL 



PROGRAM 

GETVALUE 

PRINTNUM 

PRINTEXT 

PROGSTOP 

DATA 

ENDPROG 

END 



START 

VAL, 'ENTER NBR: 

VAL 

SKIP=1 

F'O' 



OPERATOR 
ENTRY 

a. 1492 

b. -3 

c. 39000 

d. NO ENTRY 
(ENTER KEY ONLY) 

e. IB A3 



PRINTNUM 
DISPLAY 
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TERMINAL I/O REVIEW EXERCISE - ANSWERS 

1. a. program has the terminal enqueued 

b. program is suspended by a WAIT KEY operation 

2. Any three of the following: 

a. "LINE=" in a succeeding operation 

b. "SKIP=" in a succeeding operation 

c. DEQT execution 

d. an "@" character imbedded in the text of this or of a 
succeeding operation, with IVIODE=WORD in effect 

e. TERMCTRL DISPLAY execution 

f. "change of operation direction", such as a PRINTEXT 
followed by a GETVALUE or READTEXT 

3. Character position 21, line 3. The "SPACES=10" 
leaves 10 unprotected spaces between the end of the pre- 
ceding protected field, and the beginning of the 
"NEXT ENTRY" text. 

4. PF keys a, e PF keys (a) will terminate a WAIT KEY 
operation, and, when a program is not suspended by a WAIT KEY, 
and the terminal is not enqueued, may also be used in an 

ATTN LIST (e). 

ATTN key b, d T he ATTN key will not terminate a WAIT 
KEY operation (d). When the program is not in a WAIT KEY, 
and the terminal is not enqueued, the ATTN key may be used 
by the ATTNLIST function (b). 

ENTER key a, c The ENTER key terminates a WAIT KEY (a) 
(as well as the implied wait of a READTEXT/GETVALUE/ 
QUESTION), and cannot be used with ATTNLIST (c). 

5. Answer: $SYSPRTR, $SYSLOG The third "special 
system terminal", $SYSLOGA may be enqueued by user 
programs, but only by using the "ENQT/label of lOCB" 
convention, or by an ENQT with no lOCB label reference, 
when $SYSLOGA is the "loading" terminal. 



11-56 SR30-0436 



y 



OPERATOR PRINTNUM 

ENTRY DISPLAY 

a. 1492 1492 



b. -3 -3 



c. 39000 



d. NO ENTRY 

(ENTER KEY ONLY) 



e. IB A3 1 



Entries a. and b. operate normally. Entry c. is too large to be 
contained In a single word integer, so VAL is left undisturbed, 
as it is for d., when no entry is made. Entry e. is an attempt to 
enter a hexadecimal value, when "MODE=HEX" is not coded 
in the GETVALUE operand field. The input operation 
terminates when the first non-numeric character is encountered 
in the input field. 
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Section 12. Data Formatting 



DATA CONVERSION 



.y 



OBJECTIVES: After completing this topic, the student should 

1. Understand when to use the data formatting/conversion 
instructions 

2. Be able to convert numeric character strings to binary values using 
CONVTD 

3. Be able to convert binary values to EBCDIC character strings using 
CONVTB 

4. Understand the operation of GETEDIT/PUTEDIT instructions, and 
their relationship to FORMAT and TEXT statements 



For purposes of this discussion, data conversion refers to the process of 
converting arithmetic values from internal representation (binary) into 
external representation (EBCDIC character strings), or the reverse. 

You are already familiar with some forms of data conversion. As Illus- 
trated in Figure 12-1, the assembler performs data conversion when 
assembling arithmetic constants, defined in DATA statements. The 
binary values generated during the assembly are the internal equivalents 
of the externally represented values coded In the source statements. 



INTEGER VALUE 31,416 



DEFINED IN DATA STATEMENT . . . 



IVAL DATA F'31416' 



CONVERTED BY THE ASSEMBLER INTO 
A 1-WORD BINARY NUMBER, HEX 7AB8 



0111 1010 1011 1000 





Figure 12-1. Assembler data conversion 



FLOATING POINT VALUE 3.1416 



DEFINED IN DATA STATEMENT 



FVAL DATA E'3.1416' 



CONVERTED BY THE ASSEMBLER INTO A 
2-WORD (STANDARD PRECISION) BINARY 
FLOATING POINT NUMBER, HEX 4132 43FE 



0100 0001 0011 0010 0100 0011 1111 1110 
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CONVTD INSTRUCTION 



While the DATA statement can only be used to convert constants 

known at assembly time, GETVALUE converts data entered at a y- 

terminal, in "realtime." GETVALUE, and in the reverse direction, i 

PRINTNUM, not only convert arithmetic values, but carry 

the operation one step further by performing the I/O as well (see 

"Section 11. Terminal I/O"). 

These instructions, while useful, do not meet all data conversion 
requirements. For example, a numeric value read into a text buffer by 
a READTEXT instruction rather than by a GETVALUE, will be in the 
form of an EBCDIC character string, which must be converted to 
internal representation before the program can operate on it. 

Similarly, it may not always be desirable to convert an internally 
represented constant or variable and immediately display or print it, 
as occurs with PRINTNUM. You may instead want to convert it to an 
EBCDIC character string, and hold it for later output by a PRINTEXT. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "CONVTD." 

CONVTD converts an EBCDIC character string into a binary arithmetic 
value. Single and double precision integers, and standard and extended 
floating point internal formats are supported. 



CONVTD opndl,opnd2j ,PREC= ^ FORMAT= 



OPTIOIMAL MUST BE CODED REQUIRED IF 

opndl IS 
OTHER THAN 
SINGLE PRE- 
CISION 
INTEGER 

Figure 12-2. CONVTD format 

The first operand (opndl) is the label of the first byte of the storage 
area that will contain the binary equivalent of the EBCDIC string after 
it has been converted. The user must reserve enough space to hold the 
results of the conversion. This may be two bytes, for a single precision 
integer variable, four bytes, for double precision integer or standard 
precision floating point values, or eight bytes for extended precision 
floating point variables. 

The second operand (opnd2) is the label of the first character of the 
EBCDIC character string to be converted. Leading blanks or zeros are 
allowed. 
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The PREC= operand describes opndl (Figure 12-3). 

PREC= Operand opndl Description 

PREC=S Single Precision Integer (default) 

PREC=D Double Precision Integer 

PREC=F Standard Precision Floating Point 

PREC=L Extended Precision Floating Point 

Figure 12-3. PREC= operand 



Storage Required 

1 Word (2 Bytes) 

2 Words (4 Bytes) 
2 Words (4 Bytes) 
4 Words (8 Bytes) 



The FORMAT= operand is coded as a list containing three sublist 
elements, all enclosed in parentheses. The three elements describe the 
EBCDIC character string pointed to by the label In opnd2, as shown 
in Figure 12-4. 



FORMAT=(W,D,T) where; 




. . . Width of the 
EBCDIC character 
string in bytes 



Figure 12-4. F0RMAT= operand 



,y 




. . . Number of 
positions to the right 
of the decinnal point. 
Code "0" if integer. 



T 



. . . Code "I" if integer 

. . . Code "F" if real 

number 

. . . Code "E" if real 

number in "E" notation, 



If not coded, FORMAT= defaults to FORMAT=(6,0,I), indicating a 
six-byte EBCDIC field containing an integer number. 



CONVTB INSTRUCTION 



READING ASSIGNIVIENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "CONVTB." 

CONVTB converts values in internal representation (binary) form to an 
EBCDIC character string. 

label i CONVTB opndl, opndZJ ,PREC= ; FORMAT= 

OPTIONAL 



MUST BE CODED 



REQUIRED IF REQUIRED IF opndl 
opndl IS IS OTHER THAN A 

OTHER THAN 6-BYTE FIELD 
SINGLE PRE- 
CISION 
INTEGER 



Figure 12-5. CONVTB format 
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Since the direction of the operation is the reverse of CONVTD, the 
meaning of opndl and opnd2 is also reversed. The label of the left- 
most byte of the storage area, which will receive the EBCDIC string 
resulting from the conversion, is opndl and opnd2 is the label of the 
storage location containing the variable. 

The PREC= and FORMAT= operands are coded the same way for 
CONVTB as for CONVTD; because opndl and opnd2 are reversed, 
PREC= now applies to opnd2 and FORMAT= to opndl. 



CONVTD/CONVTB CODING EXAMPLES 



In Figure 12-6, the CONVTB at C1 is converting the constant at loca- 
tion C0N1 into an EBCDIC character string, which will be stored in the 
text buffer EBC1. 



CCODE 


PROGRAM 


CI 


CI 


CONVTB 


EBCl, CONl 




IF 


(CCODE, NE,-1), GOTO, CNVTERR 


PI 


PRINTEXT 


'TEXT=' 




PRINTEXT 


EBCl 




PRINTEXT 


SKIP=1 


END 


PROGSTOP 




CNVTERR 


MOVE 


CODE, CCODE 




PRINTEXT 


'CONVERT ERROR, CODE=' 




PRINTNUM 


CODE 




PRINTEXT 


SKIP=1 




GOTO 


END 


EBCl 


TEXT 


LENGTH=6 


CONl 


DATA 


F' 14398' 


CODE 


DATA 

ENDPROG 

END 


F'O' 



Figure 12-6. Return code = -1 



Completion codes for CONVTB and CONVTD operations are returned 
in the task code word (taskname). The IF statement immediately 
following the CONVTB is checking the return code for Normal Comple- 
tion (-1). In this example, the operation will be successful, and the 
PRINTEXT instructions beginning at P1 will display TEXT=14398. 

In Figure 12-7, the CONVTB is attempting to convert a value of 
21,000,000, in location C0N2, and store the resulting text string In the 
text buffer at EBC2. The text buffer is not large enough to hold the 
character string generated by the conversion, and will be set to zeros. 
The completion code will be a 3, indicating Conversion Error, and the 
IF statement following the CONVTB will transfer control to location 
CNVTERR. 

The error routine beginning at CNVTERR will display an error message 
and the completion code resulting from the operation. The first instruc- 
tion moves the completion code from taskname into the user-defined 
program variable CODE. 
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CCODE 


PROGRAM 


C2 




CONVTB 


EBC2,C0N2,PREC=DW0RD 




IF 


(CCODE, NE,-1), GOTO, CNVTERR 


PI 


PRINTEXT 


'TEXT=' 




PRINTEXT 


EBC2 




PRINTEXT 


SKIP=1 


END 


PROGSTOP 




CNVTERR 


MOVE 


CODE, CCODE 




PRINTEXT 


'CONVERT ERRROR, CODE= ' 




PRINTNUM 


CODE 




PRINTEXT 


SKIP=1 




GOTO 


END 


EBC2 


TEXT 


LENGTH=6 


C0N2 


DATA 


D'21000000' 


CODE 


DATA 

ENDPROG 

END 


F'O' 



Figure 12-7. Return code = 3. 

This is a standard convention, and is necessary because other operations, 
such as I/O, also post completion codes in taskname, and will overlay 
the code you want to display. For instance, were the I F statement 
following the CONVTB replaced by the statement 



PRINTNUM CCODE 



in an attempt to display the return code from the conversion operation, 
the code displayed would be the completion code resulting from execu- 
tion of the PRINTNUM itself, not the code returned by the CONVTB. 

When the error routine at CNVTERR completes execution, the message 
CONVERT ERROR, C0DE=3 will be displayed. A -1, for Normal 
Completion, or a 3, indicating Conversion Error, are the only comple- 
tion codes generated by CONVTB operations. 

In Figure 12-8, a CONVTD operation is attempting to convert the 
EBCDIC string in EBC3 to a binary value to be stored in location C0N3. 
The EBCDIC string consists of blanks and the delimiter " , ", This 
results in no conversion, and a completion code of 2, indicating Field 
Omitted. Commas and slashes (/) are considered arithmetic delimiters 
and, if found in a text string during CONVTD execution, vyiH terminate 
the conversion. In this example, since the delimiter (comma) was pre- 
ceded only by blanks, the Field Omitted completion code is generated 
and the program will complete execution with CONVERT ERROR, 
C0DE=2 displayed. 
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CCODE 


PROGRAM 


C3 


C3 


CONVTD 


C0N3,EBC3 




IF 


(CCODE, NE,-1), GOTO, CNVTERR 


PI 


PRINTEXT 


•VARIABLE=' 




PRINTNUM 


C0N3 




PRINTEXT 


SKIP=1 


END 


PROGSTOP 




CNVTERR 


MOVE 


CODE, CCODE 




PRINTEXT 


'CONVERT ERROR, CODE=' 




PRINTNUM 


CODE 




PRINTEXT 


SKIP=1 




GOTO 


END 


EBC3 


TEXT 


' , ' , LENGTH=6 


C0N3 


DATA 


F'O' 


CODE 


DATA 

ENDPROG 

END 


F'O' 



Figure 12-8. Return code = 2 



If the text buffer at EBC3 had contained numbers (in EBCDIC code), 
all numbers to the left of the delimiter would have been converted, 
and a completion code of -1 returned. For instance, 12,391 in the text 
buffer would convert to the binary equivalent of 12. Any non-numeric 
character imbedded within the text field will end the conversion. 

In Figure 12-9, the CONVTD at C4 is attempting to convert the blank 
text field at EBC4. This will result in a return code of +1, which 
indicates No Data In Field. The example will complete with the message 
CONVERT ERROR, C0DE=1 displayed. 



CCODE 


PROGRAM 


C4 


C4 


CONVTD 


C0N4,EBC4 




IF 


(CCODE, NE,-1), GOTO, CNVTERR 


PI 


PRINTEXT 


'VARIABLE=' 




PRINTNUM 


C0N4 




PRINTEXT 


SKIP=1 


END 


PROGSTOP 




CNVTERR 


MOVE 


CODE, CCODE 




PRINTEXT 


'CONVERT ERROR, CODE=' 




PRINTNUM 


CODE 




PRINTEXT 


SKIP=1 




GOTO 


END 


EBC4 


TEXT 


LENGTH=6 


C0N4 


DATA 


F'O' 


CODE 


DATA 

ENDPROG 

END 


F'O' 



Figure 12-9. Return code = 1 
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GETEDIT/PUTEDIT INTRODUCTION 



GETEDIT and PUTEDIT instructions combine several of the I/O and 
conversion operations already discussed. For review. Figure 12-10 
summarizes the instructions used to move data from a terminal into 
storage (READTEXT, GETVALUE) and convert it to internal 
representation (CONVTD, or implicit with GETVALUE). 






"^ GETVALUE 



10011101100\ 



READTEXT 




CONVTD 



PERFORMS 
I/O OPERATION 



CONVERTS TO 
INTERNAL FORMAT 



READTEXT GETVALUE 

GETVALUE CONVTD 

Figure 12-10. External to internal summary 



USES TEXT 
BUFFER 

CONVTD 

READTEXT 
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In Figure 12-11, the reverse operations are shown, converting and 
moving data directly to a terminal (PRINTNUM), or first converting it 
to external format (CONVTB), and then displaying it (PRINTEXT). 



[1011100/ ■ 



PRINTNUM 



CONVTB 





PRINTEXT 



PERFORMS 
I/O OPERATION 

PRINTEXT 

PRINTNUM 



CONVERTS TO 
EXTERNAL FORMAT 

PRINTNUM 

CONVTB 



USES TEXT 
BUFFER 

CONVTB 

PRINTEXT 



Figure 12-11. Internal to external summary 

PUTEDIT and GETEDIT perform all of the functions shown in 
Figures 12-10 and 12-11. The I/O plus conversion provided by 
GETVALUE and PRINTNUM is supported, but with the addition of 
the use of a text buffer. The value is therefore displayed/read (I/O), 
and is available both in external format (as EBCDIC string in text 
buffer) and in internal format. 
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GETEDIT 




1001 1101 ioo\ 



1011011/ - 




PUTEDIT 



□i 



^ 



1. Performs I/O operation (optional) 

2. Performs conversion 

3. Uses text buffer 

Figure 12-12. PUTEDIT/GETEDIT summary 

Viewed another way, the transfer of an EBCDIC string to or from a 
terminal as provided by PRINTEXT and READTEXT is supported, 
but with the addition of conversion to or from internal representation 
(CONVTD/CONVTB functions). 
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PUTEDIT/GETEDIT INSTRUCTIONS 



READING ASSIGNMENT: IBM Serles/1 Event Driven Executive 
Language Reference (SC34-1706), "GETEDIT", "PUTEDIT." 

To perform a conversion, four items of information are required: 

1. Direction of conversion (from internal representation to external, 
or the reverse). This is implicit when GETEDIT (external to 
internal) or PUTEDIT (internal to external) Is coded. 

2. Conversion specification. Length of character string and type of 
data item to be converted to or from. This information is coded 
in a FORMAT statement, and the location (label) of the FORMAT 
statement Is the first operand of the GETEDIT or PUTEDIT. 

3. Character buffer location. The second operand is the name of the 
character buffer (usually the label of a TEXT statement) that 
contains the character string to be converted (GETEDIT) or will 
hold the results of the conversion (PUTEDIT). 

4. Storage variable location. The named program storage location (s) 
containing the internally represented data item(s) that are the 
input to (PUTEDIT) or results of (GETEDIT) the conversion. 
Figure 12-13 summarizes the operand format just discussed, using 
GETEDIT as an example. (GETEDIT is used in most of the 
following illustrations, but the concepts demonstrated are equally 
valid for PUTEDIT operations. If the direction of conversion is 
taken Into account.) 



label GETEDIT 









(variable name) 
—or- 

(Cr'^'VPe)) 

— or— 
//variable A\ 
VVname '^^^^VJ 

— or— 

//variable ^ ^ \\ 

1 ,^„ ,count,type)J 

\\name II 






name of TEXT 
statement 
(location of 
character buffer) 


» 


name of 

FORMAT 

statement 


? 


X 




/ 


/ 





LABEL OF THE FORMAT 
STATEMENT THAT DESCRIBES 
THE EBCDIC DATA IN THE 
CHARACTER BUFFER TO BE 
CONVERTED (ALPHA? ARITH- 
METIC? "E" NOTATION? etc.) 



LOCATION (LABEL 
ON TEXT STATEMENT) 
OF THE BUFFER 
CONTAINING THE 
CHARACTER STRING 
TO BE CONVERTED 



LOCATION(S) IN 
STORAGE WHERE 
CONVERTED VALUE(S) 
WILL BE PLACED, 
AND THE TYPE 
(PRECISION) OF THE 
VALUES, IF ARITH- 
METIC 



Figure 12-13. GETEDIT format 
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FORMAT STATEMENT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "FORMAT." 

Figure 12-14 illustrates the basic layout of the FORMAT statement, 
and shows how it is referenced by a GETEDIT. 



label GETEDIT 



name of 

FORMAT 

statement 



name of TEXT 
statement 
(location of 
character buffer) 



CGET 



FLTFORM 




(variable name) 

— or— 

'variable 



lame 



,type 



)) 



//v= 
\\ni 

//variable ^\\ 

( .count ) J 

\\name // 

— or— 

//variable ^ ^ \\ 

( ( ,count,type ) ) 

\\name // 



—or— 



DATA 




CONVERSION 




SPECIFICATION 


MAYBE: "1" 


INTEGER NUMERIC 


"F" 


FLOATINGPOINT 




NUMERIC 


"E" 


FLOATINGPOINT 




NUMERIC -"E" 




NOTATION 


"H" 


LITERAL ALPHA- 




MERIC DATA 


"X" 


BLANKS 


"A" 


VARIABLE ALPHA- 




MERIC DATA 



MAYBE: "PUT" - THIS FORMAT STATE- 
MENT USED WITH PUTEDIT 
COMMANDS ONLY 
"GET" - THIS FORMAT STATE- 
MENT USED WITH GETEDIT 
COMMANDS ONLY 
"BOTH" - MAY BE USED WITH 
BOTH PUTEDIT AND GETEDIT 
(DEFAULT) 



Figure 12-14. FORMAT statement 
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Note that among the various types of data items that are allowed in the 
data conversion specification list are type F and type E. The type F 
indicates floating point numeric. Do not confuse this with the fixed 
point binary designated by the F that is used in DATA statements. 
Similarly, the E means E-type notation, and uoX standard precision 
floating point, as did the E used with DATA statements. By specifying 
E-type notation in the FORMAT list, the variable being described is 
implicitly considered to be a floating point value. 

Figure 12-15 is an example of a FORMAT statement, whose list 
describes a single variable, with data conversion specification type E. 
Detailed explanations of all the available data specification types, and 
examples of their use, may be found in the reading assignment. 

FORMAT 

- SPECIFIES THE TYPE OF CONVERSION TO BE PERFORMED 

WHEN DATA IS TRANSFERRED FROM STORAGE TO A TEXT 

BUFFER BY A PUTEDIT COMMAND, OR FROM A TEXT 

BUFFER TO STORAGE BY A GETEDIT COMMAND. 



EXAMPLE: WRITE A FORMAT STATEMENT THAT WILL ALLOW 
CONVERSION TO AND FROM FLOATING POINT NUMBERS 
WITHIN THE RANGE OF -9.9999 TO +9.9999, USING "E" TYPE 
NOTATION. 



FLTFORM FORMAT 



CONVERSION TYPE 

FLOATING POINT, E 
NOTATION 



(Ell. 4), BOTH 



LARGEST POSSIBLE VALUE 
SMALLEST POSSIBLE VALUE 



E NOTATION TAKES UP 



+9.9999 
-9.9999 

^ V— ' 

1234567 



7 CHARACTER 
POSITIONS 

4 CHARACTER 
POSITIONS 




MAY BE USED BY 
BOTH PUTEDIT AND 
GETEDIT 

NUMBER OF POSITIONS 
TO RIGHT OF 
DECIMAL POINT 



11 POSITIONS REQUIRED 



Figure 12-15. FORMAT statement E type 
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The second operand in the GETEDIT statement (Figure 12-16) is the 
location of the character buffer. The length of this buffer must be 
large enough to accommodate the largest character string anticipated, 
or truncation will result (254 characters maximum). 



label GETEDIT 



name of 

FORMAT 

statement 



name of TEXT 
statement 
(location of 
character buffer) 



(variable name) 
—or— 

((:re'''vpe)) 

— or— 

//variable ^\\ 

( ( .count 1 1 

y\name )) 



— or— 



//variable 
\\name 



,count,type 



)) 



CGET 



GETEDIT 



FLTFORM,FLOATEXT , 



FLOATEXT TEXT 



LENGTH=18 



FLOATEXT 
FLOATEXT + 1 
FLOATEXT +2 



FLOATEXT + 17 




LENGTH OF 

BUFFER (HEX 12 = DEC18) 

COUNT OF NUMBER OF 
INPUT CHARACTERS 
RECEIVED OR OUTPUT 
CHARACTERS TO TRANSMIT 



SPACE FOR 18 
CHARACTERS 
RESERVED 
18 BYTES) 
INITIALIZED TO 
EBCDIC BLANKS 
(HEX 40) 



Figure 12-16. Character buffer location 
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Figure 12-17 summarizes the third operand, the variable list. The 
variable names used must previously have been defined in the program 
(DATA statements). 



label GETEDIT 









(variable name) 

— or— 
//variable ^„^\\ 
((name '^^^^7 

—or— 

((nre"".--')) 
— or— 

//variable ^ ^ \\ 
((name •co"nt,typej; 






name of TEXT 
statement 
(location of 
character buffer) 


1 


name of 

FORMAT 

statement 


T 













CGET 



GETEDIT FLTFORM,FLOATEXT,((name, count, type)) 



STORAGE LOCATION 
TO PUT VALUE 
CONVERTED FROM 
CHARACTER STRING 
IN BUFFER 




MULTIPLE LOCATIONS IF 
MULTIPLE CONVERSIONS 



TYPE/PRECISION 

OF VARIABLE 

"S"OR "D" INDICATES 

SINGLE OR DOUBLE 

WORD INTEGER 

(DEFAULT=SINGLE) 

"F"OR "L" INDICATES 

STANDARD OR EXTENDED 

PRECISION FLOATING POINT 

(DEFAULT=STANDARD) 



Figure 12-17. Third operand summary 
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If arithmetic variables are being converted, the data type specified must 
agree with the data conversion specification in the FORMAT statement 
(F or L in GETEDIT must have either F or E in FORIVIAT statement, 
and S or D in GETEDIT corresponds with I in FORMAT statement). 

The completed GETEDIT statement is shown in Figure 12-18, with all 
three operands coded. To illustrate the optional I/O capability, a 
fourth operand, ACTlbN= is also coded. The more common usage 
(and the default) is ACTION=l/0, meaning a GETEDIT or PUTEDIT 
would implicitly issue a READTFXT or PRINTEXT. With 
ACTION=STG, the GETEDIT or PUTEDIT assumes the user will take 
care of transferring the EBCDIC character string from or to the 
terminal by issuing explicit READTEXT or PRINTEXT commands as 
required. 



GETEDIT 



GETS EBCDIC CHARACTER STRING FROM A CHARACTER 
BUFFER SET UP BY A TEXT STATEMENT 

CONVERTS EBCDIC CHARACTER STRING ACCORDING TO 
SPECIFICATIONS IN FORMAT STATEMENT, AND PLACES 
RESULT OF CONVERSION IN STORAGE 

MAY OPTIONALLY ISSUE A READTEXT COMMAND TO 
TRANSFER EBCDIC CHARACTERS FROM A TERMINAL 
INTO THE CHARACTER BUFFER, BEFORE BEGINNING 
CONVERSION 



EXAMPLE: CONVERT THE EBCDIC CHARACTER STRING IN THE 
CHARACTER BUFFER DEFINED BY THE TEXT STATEMENT AT 
LOCATION "FLOATEXT" INTO A STANDARD PRECISION 
FLOATING POINT NUMBER, ACCORDING TO THE SPECIFICA- 
TIONS OF THE FORMAT STATEMENT AT LOCATION "FLTFORM". 
STORE THE RESULT AT LOCATION "FVAL". 



CGET GETEDIT FLTFORM, FLOAJEXT, ( (FVAL, F) ) ,ACTION=STG 

\ 



LOCATION OF 

FORMAT 

STATEMENT 



LOCATION OF 
CHARACTER 
BUFFER (TEXT 
STATEMENT) 



OUTPUT 

DATA 

LOCATION 



OUTPUT 

DATA 

TYPE 

(FLOATING 

POINT) 



CONVERT ONLY- 
DO NOT ISSUE 
READTEXT 
COMMAND 
BEFORE 
CONVERSION 
STARTS 



Figure 12-18. Completed GETEDIT 
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As a comparison, the same operation in reverse is illustrated in 
Figure 12-19. 



PUTEDIT 



CONVERTS DATA IN STORAGE INTO EBCDIC CHARACTER 
STRING, ACCORDING TO SPECIFICATIONS IN FORMAT 
STATEMENT 

PLACES EBCDIC CHARACTER STRING IN CHARACTER 
BUFFER SET UP BY TEXT STATEMENT 

MAY OPTIONALLY ISSUE A PRINTEXT COMMAND TO 
TRANSFER CONTENTS OF THE CHARACTER BUFFER TO 
A TERMINAL DEVICE AFTER CONVERSION 



EXAMPLE: CONVERT THE STANDARD PRECISION FLOATING 
POINT VARIABLE AT STORAGE LOCATION "FVAL" INTO AN 
EBCDIC CHARACTER STRING, ACCORDING TO THE SPECIFICA- 
TIONS IN THE FORMAT STATEMENT AT LOCATION "FLTFORM' 
PLACE THE EBCDIC STRING IN THE CHARACTER BUFFER DE- 
FINED BY THE TEXT STATEMENT AT LOCATION "FLOATEXT". 



CPUT 



PUTEDIT 




FLTFORM, FLOATEXT, ( (FVAL, F)),ACTII 

/ \ 



J=STG 



LOCATION OF 


LOCATION OF 


LOCATION OF 


INPUT 


CONVERT 


FORMAT 


CHARACTER 


INPUT DATA 


DATA 


ONLY-DO 


STATEMENT 


BUFFER (TEXT 




TYPE 


NOT ISSUE 




STATEMENT) 




(FLOATING 
POINT) 


PRINTEXT 
COMMAND 
AFTER 
CONVERSION 



Figure 12-19. Completed PUTEDIT 



All operands are in the same position, and have the same meanings for 
PUTEDIT as for GETEDIT; only the operation direction is reversed. 

Figure 12-20 is an overview of a complete GETEDIT operation using 
the same examples of GETEDIT, TEXT, and FORMAT as you have 
seen in the previous figures. Following the numbers on the illustration, 
the characters entered at the terminal SB , are transferred to the text 
buffer by the READTEXT instruction Q . In this example, the 
READTEXT is issued by the user sometime prior to execution of the 
GETEDIT. If ACTION=l/0 were coded in the GETEDIT (or not 
coded, and allowed to default), the READTEXT would be automatically 
issued by the GETEDIT. 
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OPERATOR ENTERS 
CHARACTERS ".31416E 01' 




READTEXT FLOATEXT 



TRANSFERS EBCDICSTRING " 4BF3F1F4F1F6C540F0F 1" 
FROM TERMINAL INTO TEXT BUFFER 



FLOATEXT TEXT LENGTH=18 



LENGTH 
COUNT - 



-FLOATEXT' 



FLOATEXT + 17 



1 2 



A 



4 B 



F 3 



F 1 



F 4 



F 1 



CGET GETEDIT FLTFORM, FLOATEXT, ( (FVAL ,F) ) ,ACTION=STG 



CONVERTS EBCDIC CHARACTER STRING INTO 
BINARY FLOATING POINT NUMBER-STORES 
AT LOCATION "FVAL" 




FLTFORM FORMAT (Ell. 4), BOTH 



Figure 12-20. GETEDIT overview 
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The GETEDIT Q , using the FORMAT statement FLTFORM Q , 
converts the EBCDIC character string in the text buffer at FLOATEXT 
B Into a standard precision floating point value, which is stored at 
FVAL O • 

Note: Support for GETEDIT/PUTEDIT/FORMAT instructions is 
supplied in the form of object modules. When a user program 
containing GETEDIT/PUTEDIT/FORMAT statements is assembled, 
$EDXASM automatically generates corresponding EXTRN records 
for use by the link edit utility $LINK. 

After an object module has been produced by $EDXASM, it must be 
processed by $LINK to include the data-formatting object modules. 
The user must code the AUTO= parameter in the link edit OUTPUT 
control statement as AUTO=$AUTO,ASMLIB. $AUTO is the name of 
a system-supplied data set on ASM LIB, which contains an autocall 
list, including entries for the GETEDIT/PUTEDIT/FORMAT 
support modules. 
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DATA FORMATTING REVIEW EXERCISE-QUESTIONS 



Match the instructions on the left with the statements on the right. The 
instructions may apply to more than one statement, and the same 
statement may be true for more than one instruction, or not true for 
any. 



a. 
b. 
c. 
d. 
e. 
f. 

g- 

h. 



CONVTD 

PRINTNUM 

GETEDIT 

CONVTB 

PRINTEXT 

GETVALUE 

PUTEDIT 

READTEXT 



1. 
2. 

3. 
4. 

5. 
6. 

7. 
8. 
9. 



always requires a text buffer. 

used to read numeric values from 
a terminal and convert them to 
internal (binary) representation. 

may optionally perform I/O. 

cannot be used for internal/external 
or external/internal conversion. 

never performs I/O. 

used to convert an EBCDIC string 
in a text buffer to a binary value. 

never requires a text buffer. 

always performs I/O. 

may be used to convert both float- 
ing point or integer values. 
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DATA FORMATTING REVIEW EXERCISE-ANSWERS 



1. CONVTD (a), GETEDIT (c), CONVTB (d), PUTEDIT (g), and 
READTEXT (h) always require a text buffer. PRINTEXT (e) 
usually uses a text buffer, but may be used to issue forms control 
commands without any transfer of text. GETVALUE usually 
uses a text buffer, either implicit, as the pmsg operand, enclosed 
in apostrophes, or as an explicitly coded TEXT statement but 
may be coded without a prompt message, and therefore no text 
buffer. 

2. GETEDIT (c) and GETVALUE (f) may be used to read numeric 
values from a terminal and convert them to internal (binary) 
representation. GETEDIT can read and convert multiple values, 
integer and floating point or mixed integer and floating point, of 
varying external format. GETVALUE can read multiple single 
precision integers. If the external format of the Input value is 
other than single precision integer (double precision Integer, 
standard or extended precision floating point in either F or E 
format), then the format of the input variable must be specified 
in the FORMAT= operand, the internal format must be specified 
in the TYPE= operand, and only one value can be read and 
converted by execution of a single GETVALUE instruction. 

3. GETEDIT (c) and PUTEDIT (g) may optionally perform I/O. If 
the ACTION= operand is coded as ACTION=STG conversion will 
be performed between the internally represented variables and 

the text buffer specified, but no data transfer to or from a terminal 
will take place. 

4. PRINTEXT (e) and READTEXT (h) cannot be used for internal/ 
external or external/internal conversion of numeric values. These 
two instructions deal in the transfer of text strings between storage 
and terminals exclusively. There may be code conversion per- 
formed, from the EBCDIC representation in a text buffer to or 
from whatever unique code a particular terminal requires, but this 
is an automatic function of the system, is transparent to the user, 
and is not the conversion of arithmetic values which was defined 
as data conversion In this section. 

5. CONVTD (a) and CONVTB (d) never perform I/O. These instruc- 
tions always operate between variables and text buffers in storage. 
All other instructions listed either always, or optionally may 
perform I/O. 

6. CONVTD (a) and GETEDIT (c) are used to convert an EBCDIC 
string in a text buffer to a binary value. The GETEDIT may also 
have read the value into the text buffer from a terminal 
(ACTION=l/0). 
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PRINTNUM (b) never requires a text buffer. The conversion 
is from the binary value to the code required by the terminal, with 
no user defined text buffer employed. GETVALUE (f) does not 
require a text buffer for the conversion, but may use one for the 
prompt message if the pmsg operand is coded. 

PRINTNUM (b), PRINTEXT (e), GETVALUE (f), and 
READTEXT (h) always perform I/O. I/O is optional with 
GETEDIT (c) and PUTEDIT (g). 

CONVTD (a), PRINTNUM (b), GETEDIT (c), CONVTB (d), 
GETVALUE (f), and PUTEDIT (g), all handle single and double 
precision integers, and standard or extended precision floating 
point numbers in F or E notation external formats. PRINTEXT 
(e) and READTEXT (h) do not perform any conversion, and 
therefore do not apply. 
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Section 13. Sensor I/O 



OBJECTIVES: Upon successful completion of this topic, the student 
should be able to: 

1. Define the sensor I/O requirements in an application program. 

2. Understand how to obtain digital and analog data from external 
devices. 

3. Understand how to send digital and analog output signals from the 
Series/1 to external devices. 

4. Use the facilities provided to service process interrupts on a 
Series/1. 



SENSOR BASED I/O 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
System Guide {SC34-1702), "Sensor I/O." 

"Data Processing Input/Output" refers to the exchange of information 
between a computer and a data processing I/O device. An example of 
this is shown In Figure 13-1 in the form of an operator entry at a 
terminal, which the program in the computer then transfers into stor- 
age, and acts upon. 
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Figure 13-1. Data processing I/O 
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Depending on what the input means to the program, an information 
message or guidance prompt may be sent back to the terminal operator 
in response. 

In Figure 13-2, the same example has been put into an applications 
context. Assume that the program is a "flow monitoring" application, 
related to some industrial process. A gauge is connected to a pipe, 
indicating the rate of flow through the pipe. The rate of flow can be 
adjusted using the valve. 
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Figure 13-2. Flow monitoring 



In response to a prompt from the program, the operate, reads the 
gauge, and enters the rate of flow at the terminal. The program trans- 
fers the information into storage and checks the entered flow rate 
against predetermined limits or targets. If the flow rate is too high or 
too low, the program sends a message to the terminal instructing the 
operator to adjust the valve down or up. 

In the example just discussed, a computer program is used to analyze 
a measurement of some physical property (in this case, rate of flow in 
pipe), and based on that analysis, request that a mechanical action take 
place (turn the valve up or down). The human operator, using the 
terminal, provided the flow rate information to the program, and as a 
result of a message on the terminal, provides the power to turn the 
valve. 
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Using the "Sensor Based Input/Output" features of the Series/1, the 
same application can be performed without using an operator or a 
terminal. In Figure 13-3, the gauge has been replaced by another flow- 
monitoring device, which translates flow rate into a voltage propor- 
tional to the rate of flow, rather than into movement of a needle 
around a dialface. The voltage produced is therefore an analog of the 
rate of flow within the pipe. 
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Figure 13-3. Sensor based I/O flow monitoring 



The voltage is sensed by the Series/1 Analog Input (A/I) feature, and 
converted to a digital value (binary). This value can then be arithmeti- 
cally compared with known limits or targets, and a decision can be 
made whether to decrease or increase the valve opening. 

The manually operated valve has been replaced by a motorized unit. 
The direction and amount of rotation of the motor drive can be con- 
trolled by the Digital Output (D/0) sensor I/O feature. 

The entire "flow-monitoring" application can now be directly con- 
trolled by the program, from acquisition of the flow-rate information 
(A/I), through the performance of the corrective mechanical adjust- 
ment (D/0). The delays and errors inherent in operator participation in 
the process no longer exist. 
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Sensor I/O is used in a variety of application areas, including process 
control, laboratory automation, and plant automation. Sensor I/O 
devices available on the Series/1 are as follows; 



Digital Input/Output 



Analog Input/Output 



A digital unit of sensor I/O is a physical group of 16 contiguous points. 
The entire group of sixteen points is accessed as a unit at the I/O in- 
struction level; Event Driven Executive programming support allows 
logical access down to the single point level. Each point of Digital Input 
(D/l) or Digital Output (D/0) may be operated (turned on/off) inde- 
pendently. D/l is usually used to acquire information from Instruments 
which present binary-encoded output, or to monitor contact/switch 
status (open/closed). D/0 is used to control electrically operated de- 
vices through closing relay contacts, pulsing stepping motors, etc. 

Process Interrupt (P/l) is a special form of D/l. If a point of D/l 
changes state, and then changes state again, without an intervening 
READ operation from the program, the status change will be undetected. 
With P/l, a point changing from the off state to on generates a hardware 
interrupt, which is then routed, through software support, to an inter- 
rupt servicing user program which can respond to the external event 
which caused the interrupt. P/l is often used for monitoring critical or 
alarm conditions, which must be serviced quickly, and whose occur- 
rence must not go undetected. 



A physical unit of Analog Input (A/I) may be a group of 8 points or 16 
points, depending on the type. Analog Output is Installed in groups of 
2 points. Each point of A/I and A/0 is accessed separately, at both the 
I/O instruction and Event Driven Executive support level. 

Analog Input is used to monitor devices that produce output voltages 
proportional to the physical variable or process being measured. Ex- 
amples include laboratory instruments, strain gauges, temperature sen- 
sors, or other "non-digitizing" Instruments. Digital Input was des- 
cribed as monitoring an on/off status; only one of two conditions were 
possible. With A/I, the intelligence is carried in the amplitude of the 
voltage sensed rather than in its presence or absence. 
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Analog input voltages are converted to corresponding binary equiva- 
lents for use by tiie system, by the use of an Analog to Digital (A to D) 
converter. Figure 13-4 is a schematic of the analog input conversion 
mechanism. 
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Figure 13-4. Analog to digital conversion 



The address of the point to be "read" (sensed) is sent to a multiplexor 
D which selects the requested point. The voltage at the selected 
point Q is routed through the multiplexor to the Analog to Digital 
Converter Q . The A to D converter changes the voltage into an 
equivalent binary value, which can then be used in the Series/1 Q . 



With Analog Output, this process is reversed. In Figure 13-5, a binary 
value D which is the equivalent of a desired voltage, is converted to 
that voltage by a Digital to Analog Converter B , and transferred to 
the specified output point Q . 

For more detailed information about Series/1 Sensor I/O Features, see 
"IBM Series/1 4982 Sensor I/O Unit Description" (GA34-0027). 
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Figure 13-5. Digital to analog conversion 
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EVENT DRIVEN EXECUTIVE SENSOR I/O SUPPORT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Systenn Guide (SC34-1702), "SENSOR 10 Configuration Statement." 

The Event Driven Executive supplied supervisor as sent from RID con- 
tains no support for sensor I/O. If you wish to use these devices, you 
must do a "tailored system generation" to include the required support 
modules in your own supervisor. (See the "System Generation" section 
of this study guide for more information on generating a "tailored 
supervisor".) 

Figure 13-6 is a graphic depiction of how sensor devices are connected 
to a Series/1. The devices themselves (D/l, D/0, P/l, A/0, A/I) attach 
to a controller, which in turn attaches to the Series/1. The sensor I/O 
attachment (controller), and each of the devices attaching to it, have 
unique hardware addresses. In this illustration, the physical connec- 
tions are there, and the hardware addresses are assigned (wired in), but 
the supplied supervisor in storage lacks the support necessary to operate 
the devices. 



SERIES/1 



SUPPLIED 
SUPERVISOR 



SENSOR I/O 
ATTACHMENT 




ADDRESS 48 




D/0 GROUP 
ADDRESS 50 



D/l GROUP 
ADDRESS 51 



D/l GROUP 
ADDRESS 52 



Figure 13-6. Sensor device connections 
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Building a "tailored supervisor" involves the assennbly of a series of sys- 
tem configuration statements that reflect the I/O configuration and 
application requirements you wish to support. The system configura- 
tion statement which allows you to define sensor I/O devices is 
SENSOR 10. Figure 13-7 illustrates the results of a tailored sysgen, 
using the SENSOR 10 system configuration statement to generate the 
necessary control blocks, and with sensor I/O supervisor support mod- 
ules included. 



TAILORED SYSGEN 



SENSORIO ADDRESS=48,DEVICE=4982,D0=50,DI=(51,52) 
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Figure 13-7. SENSORIO 
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lODEF STATEMENT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference {SC34-1706), "lODEF." 

The SENSOR 10 statement defined the hardware device addresses for 
the supervisor. When programs reference I/O devices, they use sym- 
bolic references, rather than actual addresses. The lODEF statement 
(I/O Definition) establishes the logical link between the addresses de- 
fined in the supervisor, and the symbols used to read from and write to 
the devices at those addresses from within an application program. 

Figure 13-8 illustrates an lODEF statement. Each different logical 
sensor device that may be used by a program must be defined in an 
lODEF statement. In the example, the first operand is the syrhbolic 
name of the device, "D01". The "DO" portion of "D01" Is required, 
if you are defining a Digital Output device. The numeric portion may 
be any number you wish, from 1 through 99 (the "1" in "D01" does 
not mean "1st DO device on the adapter". It is simply a symbolic 
reference number, used to differentiate between multiple logical 
devices of the same type.) 

Each kind of sensor I/O is designated in the same manner; the alpha 
portion of the symbolic reference indicates the type of device (D/0, 
D/l, A/0, A/I, P/l), and the numeric portion differentiates between 
logical devices of the same type, and is user assigned. 

The second operand in the example is coded as "TYPE=GROUP". This 
means that the logical digital output device, whose symbolic name is 
"D01" consists of an entire group of D/0 points (16 points in a group). 
The third operand specifies that the hardware address of this group is 
50, which ties back to the hardware address for this group defined in 
the supervisor, during system generation. 

You do not have to define a logical D/0 or D/l device as consisting of 
all sixteen points of a hardware group. The second operand may be 
coded as "TYPE=SUBGROUP", in which case a fourth operand must 
be coded (BITS=), indicating which bit, or group of bits, within the 
hardware group of 16 at this address, constitutes the logical device de- 
fined by operand 1. You can therefore have multiple logical devices 
defined in the lODEF statement, all referencing the same physical ad- 
dress (group of points). 
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SENSORIO ADDRESS=48,DEVICE=4982,D0=50,DI=(51,52) 



"ADDRESS=50" IN 
lODEF CORRESPONDS 
TO THE D/0 GROUP AT 
ADDRESS 50 THAT 
WAS DEFINED IN THE 
SUPERVISOR BY THE 
"SENSORIO" 



lODEF DOl, TYPE=GROUP, ADDRESS=50 




THE KIND OF SENSOR I/O 
BEING DEFINED (DO IS 
DIGITAL OUTPUT, Dl IS 
DIGITAL INPUT, ETC.) 




SYMBOLIC 

REFERENCE 

NUMBER 



"DOl " USED FOR SYMBOLIC 
REFERENCES IN PROGRAM 



"GROUP" INDICATES THAT 
A REFERENCE TO "DOl" 
INCLUDES ALL 16 POINTS 
OF THE D/0 GROUP AT 
ADDRESS 50 



Figure 13-8. lODEF statement 
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SBIO STATEMENT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Language Reference (SC34-1706), "SBIO." 

Now that the supervisor can access the hardware (SENSOR 10, system 
generation), and you have defined the logical sensor I/O devices that 
will be symbolically referenced in your application program (lODEF), 
you are ready to do sensor I/O operations. 

All sensor-based input/output operations are performed by execution 
of an SBIO statement. The type of operation is determined by the 
type of device referenced In the SBIO (READ=DI, Al, WRITE=DO, 
AO). In the example in Figure 13-9, the contents of location "ACON" 
will be written to the symbolic device "D01 ", turning on the first eight 
digital output points of the D/0 group at address 50, and turning off 
the second eight bits. The symbolic reference to logical device "D01" 
in the SBIO statement is linked to the definition of "D01" in the 
lODEF statement, which relates that device to the sixteen digital out- 
put points of hardware address 50, through the supervisor support set 
up at sysgen. 
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ADDRESS 48 




D/0 GROUP 
ADDRESS 50 



D/l GROUP 
ADDRESS 51 



D/l GROUP 
ADDRESS 52 



SENSORIO ADDRESS=48,DEVICE=4982,D0=50,DI=(51,52) 



"ADDRESS=50" IN 
lODEF CORRESPONDS 
TO THE D/0 GROUP AT 
ADDRESS 50 THAT 
WAS DEFINED IN THE 
SUPERVISOR BY THE 
"SENSORIO" 



lODEF D01,TYPE=GR0UP,ADDRESS=50 




"DOV'INSBIO 
►CORRESPONDS TO 
"DOV'IN lODEF 



SBIO D01,AC0N 



DATA X'FFOO 



Figure 13-9. SBIO statement 
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Sensor I/O Coding Examples 



Following are a few lODEF/SBIO coding examples using various sensor 
I/O features. In all cases, assume that a tailored sysgen has been accom- 
plished using a SENSOR 10 statement which supports the addresses 
referenced in the lODEF statements in the examples. 



Digital Input 



DIGINl DATA F'O 



ODEF DI1,TYPE=SUBR0UP,ADDRESS=66,BITS=(0,8) 



SBIO DIl, DIGINl 



Figure 13-10. D/l example 



The lODEF defines "DM" as being the first 8 bits of the D/l group at 
hardware address 66. The SBIO instruction will read these 8 bits, right 
justified Into location "DIGIN1". 
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Process Interrupt 



The interrupting digital input (process interrupt) provides a hardware 
interrupt to the Series/1 when a contact closure is detected. These 
interrupts are serviced by your supervisor by POSTing that the event 
(interrupt) has occurred. You must interrogate in your program for 
event completion. When you define a process interrupt (lODEF) the 
symbolic reference (PIx) is the label on the event control block (ECB) 
for that process interrupt point(s). You can check to see if the event 
has occurred by either checking the ECB (it will be a non-zero value if 
the interrupt has occurred) or by WAITing on the process interrupt. 
The following shows how you can check the ECB. 



lODEF PI1,ADDRESS=68,BIT=10 



RESET PIl 

INTPTIM STIMER 1000, WAIT 

CHECK IF (PIltNETo'),GOTO,INTSERV 

GOTO INTPTIM 



LABEL ON ECB 



INTSERV RESET PIl 

INTERRUPT 

SERVICING 

ROUTINE 

GOTO INTPTIM 



Figure 13-11. P/l example 1 
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In the previous example we are checking every second to see if an inter- 
rupt has occurred. The program must be invoked and remain resident 
for the duration of checking for interrupts. The following shows a 
more efficient way of accomplishing the same thing. 



lODEF PI1,ADDRESS=68,BIT=15 



INTROUT WAIT PIl, RESET 
INTERRUPT 
y SERVICING 
ROUTINE 

GOTO INTROUT 

Figure 13-12. P/l example 2 



ECB LABEL 



In this example, the WAIT is issued against the ECB itself, rather than 
checking after a time delay. 

In both cases the process interrupt is handled by the supervisor and the 
user services the interrupt in a resident application program. 

For some applications, the overhead involved in allowing the supervisor 
to service and route the interrupt is not acceptable. Using the SPECPI 
statement, the user can direct that the interrupt bypass the supervisor 
and be handled by a user written assembler language routine within the 
application program. This approach provides minimum delay from the 
time the interrupt occurs until the user program is entered, but also 
requires the user to issue the I/O instructions which read and reset the 
P/l group, and to interface properly with the supervisor at the assembly 
language level. 
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Digital Output 



Digital Output is similar to D/l in terms of coding the lODEF and SBIO 
instructions with one exception. D/0 has the capability to send pulses, 
turn a D/0 point on or off for a period of time, then reverse its state. 
This is useful in driving pulse-operated devices such as stepping motors. 



lODEF D01,TYPE=SUBGR0UP,ADDRESS=67,BITS=(15,1) 



SBIO DOl, (PULSE, UP) 



Figure 13-13. D/O example 

The above example would send a pulse to the device attached to bit 15 
of the digital output group at hardware address 67. As shown, bit 15 Is 
assumed to be off, or in the "DOWN" state when the operation begins. 
The "UP" says "turn bit 15 on, and then back off". "ON" may be sub- 
stituted for "UP", and if going in the other direction, "OFF" may be 
used instead of "DOWN" when coding D/0 pulse operations. 
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External Sync 



Both D/l and D/0 may be used with external synchronization. The 
hardware has the capability of being "triggered" by a signal generated 
by a user device external to the Series/1 . 



SBIO DI1,DIW0RD,1 



DIWORD DATA 



ODEF DI 1 ,TYPE=EXTSYNC ,ADDRESS=66 



F'O 



Figure 13-14. External synchronization 

In the example shown above, the group at hardware address 66 will be 
read into location "DIWORD" only when the external synchronization 
signal is received. 

The third operand in the SBIO statement is the number of times 
(count) you wish the D/l group read (how many external sync signals 
are to be waited for) before the supervisor posts the ECB, and execution 
continues. 



L 
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Analog Input 



lODEF AI1,ADDRESS=62,P0INT=2,RANGE=5V 



SBIO 



AIVAL 



AI1,AIVAL 



DATA 



F'O 



Figure 13-15. Analog input (A/I) example 



The example above shows the reading and conversion of A/I point 2, 
defined in the lODEF as symbolic A/I device "All", When the conver- 
sion is complete, an I/O interrupt is generated, and the supervisor posts 
an ECB so that execution may continue. 

The electrical value is between ±5 volts (range). To further carry out 
the example, let's say the point had a value of 2.5 volts. The converted 
digital value in the word "AIVAL" is shown below. 



0100000000000001 



SIGN Bl 

0=POSITIVE 

1=NEGATIVE 



L. n 



BINARY REPRESENTATION 
OF CONVERTED VOLTAGE 
(+2.5V SHOWN) 



RANGE 

(±5V RANGE SHOWN) 



NOT 
USED 



Figure 13-16. A/I conversion 



For a more detailed description of A/I voltage conversion values refer to 
"IBM Series/1 4982 Sensor I/O Unit Description" (GA34-0027). 
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Analog Output 



Analog Output sends a voltage to an external user device. The program 
provides the binary (digital) equivalent of the desired output voltage to 
the A/0 device, which then converts it to voltage and puts it out to the 
specified point. 



lODEF A01,ADDRESS=64,P0INT=0 



SBIO 



VOLTOUT DATA 



A01,V0LT0UT 



X'7FC0' 



Figure 13-17, Analog output (A/O) example 

The above illustrates the "writing" of +5.0 volts to analog output point 
zero. A/0 does not generate an interrupt upon completion or employ 
external synchronization. 

The format of the output word at location "VOLTOUT" is shown be- 
low. 



USED FOR 
SIGN IF 
BIPOLAR- 
A/0 IS 
INSTALLED 



0111111111000000 



BINARY EQUIVALENT 
OF OUTPUT VOLTAGE 
(+5V SHOWN) 



UNUSED 
BITS 



Figure 13-18. A/0 conversion 

For a more detailed description of A/0 voltage conversion values refer 
to "IBM Series/1 4982 Sensor I/O Unit Description" (GA34-0027). 
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SENSOR I/O REVIEW EXERCISE - QUESTIONS 



1 . Can a user access Sensor I/O devices executing under the Starter 
Supervisor? (Yes or No) 

2. Using 

lODEF AI1,ADDRESS=70,POINT=2 

what will the following Instruction accomplish? 

a. SBIO AI1,TABLE,2 

b. SBIO AI1,TABLE,2,SEQ=YES 

3. Using 

lODEF DI10,ADDRESS=71,TYPE=SUBGROUP,BITS={8,2) 
what will the following instruction do? 
SBIO DI10,DATA1 

4. Using 

lODEF D09,ADDRESS=72,TYPE=EXTSYNC 
what will the following instruction do? 
SBIO D09,DATA,1 
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SENSOR I/O REVIEW EXERCISE -ANSWERS 

1. No {you must generate a tailored supervisor to access Sensor I/O). 

2. a. Will read A I point 2 at address 70 two times and store the 

converted values at the two locations at TABLE. 

b. Will read Al points 2 and 3 once each and store the converted 
values at the two locations at TABLE. 

3. Will read bits 8 and 9 of Dl group at address 71 into storage 
location DATA1 (right justified) 

4. Will write out the contents of storage location DATA to DO 
group at address 72 upon receipt of an external signal (pulse). 
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Introduction to Sections 14 Through 18 



The last five sections of this study guide are: 

Section 14. Utility Programs 

Section 15. System Installation 

Section 16. Program Preparation Using $EDXASI\/I 

Section 17. Program Preparation Using $S1 ASM 

Section 18. Session Manager 

These topics address areas of the system that are most subject to 
change when new operating system versions are released. New utility 
programs may be added, or existing utilities changed or expanded in 
function. Almost any change to the system will also change the 
system installation process to some extent. Maintenance and/or 
enhancement of the assemblers may alter the way certain assembler 
functions are invoked, or change the appearance of assembler output 
listings. 



Section 14. Utility Programs 



OBJECTIVES: Upon successful completion of this topic, the student 
should be able to: 

1 . Describe the purpose of each of the operator commands and system 
utility programs 

2. Use the most often required utilities 

OPERATOR COMMANDS 

When the ATTN key on a terminal Is pressed, the system responds with 
the prompt character " >". An operator may then enter a character 
string defined in an application program's ATTN LIST statement, 
thereby executing a user attention routine. 

There are also several operator commands that may be entered In 
response to the > prompt, which will cause execution of supervisor 
utility functions. The $L entry Is one example with which you are 
already familiar. $L enqueues the system loader in preparation for 
loading a user or system program to storage. 

-^ Other system commands that may be entered In response to the ">" 

ATTN key prompt are: 



$A 



Terminals are logically assigned or linked to particular partitions in 
storage, by the PART= operand of the TERMINAL system configura- 
tion statement. (For systems with < 64K of storage, all terminals 
are assigned to partition 1 by default.) When $A is entered in response 
to the " >" prompt, the system will display the names and load points 
of all programs that are active within the partition to which the request- 
ing terminal is currently assigned (see "$CP" discussion below for how 
to dynamically change the partition assignment for a terminal). The 
command $A ALL will display all partitions, their sizes, origins and all 
active programs. 
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$B 



$C 



$D and $P 



$CP 



During normal system operation, there may be occasions when a 4978/ 
4979/3101 Display screen becomes cluttered with residual displays 
from previous program executions. An example might be some pro- 
tected data areas left by an application program that terminated with- 
out issuing an ERASE command. The $B operator command will com- 
pletely erase (blank) all protected and unprotected areas of the screen 
of the requesting terminal. 



This operator command is the cancel program function, and is provided 
as a last resort to force a program to end execution and release the 
storage it occupies. It is not a normal means of terminating program 
execution, and, depending on what the cancelled program is doing 
when the cancel is issued, may result in unpredictable errors. It 
is designed as a debug aid, and should be used with discretion. 

$C is effective only within the partition assigned to the requesting 
terminal. The operator will be prompted for the name of the program 
to be cancelled, and also for the load point, if multiple copies of the 
program are in execution at the same time. 



These two commands are on-line debug aids, which allow an operator 
to display ($D) the contents of storage in hex, or to patch {$P) storage 
locations from the terminal. These commands will prompt the 
terminal operator for starting addresses, number of words, etc., and like 
$A and $C, are effective only within the assigned partition. 



The $L, $A, $C, $D, and $P functions are all restricted to the assigned 
partition, as specified in the PART= operand of the TERMINAL 
system configuration statement defining a particular terminal. The $CP 
entry Is the "change partition" command, allowing dynamic reassign- 
ment of a terminal to a partition. When $CP is entered, the operator is 
prompted for the number of the partition to be assigned to the terminal 
requesting the partition change. When the reassignment is made, all 
of the assigned partition only functions are effective for the new 
partition. See the topic "Operator Command Example" later in this 
section for an illustration of how the $CP function, along with $A and 
$C, may be used. 
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r~ 



$E 



$S 



$T and $W 



When system utility or application program output is directed to 
$SYSPRTR, the forms are usually not advanced far enough, when 
the output is finished, to allow the operator to tear off the complete 
report. The $E function advances $SYSPRTR to the top of form 
(page eject), allowing the operator to adjust the forms position until 
the complete output may be removed. 



The Spooling facility provides the function of routing printer output 
to disk for later printing. Using the $S operator command, a user can 
control the actions of the Spool facility. 



The $T entry is the set date and time command for the 24 hour system 
clock/calendar. This command may only be issued from the terminals 
designated as $SYSLOG or $SYSLOGA. The date and time may be set 
anytime, as illustrated below. 



>$T 



DATE(M.D.Y ): 110.6.78 



TIME(H.M): 11376 



DATE = 10/06/78 TIME = 13:06:36 

Figure 14-1. $T command 



Note: In Figure 14-1, and in all illustrations in this section, depicting 
operator/utility prompt/response sequences, operator entries will be 
shown enclosed in boxes. 

The $W command displays the 24 hour clock and the date, and may 
be entered from any terminal. 



> 



$W 



DATE = 10/06/78 TIME = 13:06:53 

Figure 14-2. $W command 
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$VARYON and $VARYOFF 



OPERATOR COMMAND 



The $VARYON and $VARYOFF commands allow a terminal operator 
to place tape or diskette devices in an online ($VARYON) or offline 
($VARYOFF) status. $VARYOFF might be useful in a situation where 
program testing and development are going on, and the operator wishes 
to make certain that production data residing on a diskette is inaccess- 
ible to the test programs. 

SVARYON is frequently used to place diskette volumes online. At 
system IPL, if a diskette is not mounted in the diskette drive, the 
diskette device is placed offline. When a diskette is mounted, or when 
a mounted diskette volume is removed and another volume mounted, 
the operator must issue a $VARYON to place the device and volume 
online. 



> SVARYON 



lODA = 
ASMVOL 



02 



ONLINE 



Figure 14-3. $VARYON command 

In Figure 14-3, the diskette volume ASMVOL has been mounted, and 
placed online with a $VARYON command. 

Notice that $VARYOFF and $VARYON prompt the operator for an 
I/O Device Address (IODA=). These commands are effective at a device 
level, and across the entire system. 



The following is a hypothetical situation designed to illustrate the use of 
the $A, $C, and $CP operator commands. 

We have made two assumptions: 

1. A three partition Event Driven Executive system with partition 1 
assigned to a 4979 ($SYSLOG), partition 2 assigned to a 4978, 
and partition 3 assigned to a TTY device 

2. Program debug and testing is going on in partition 1, a production 
job is running in partition 2, and partition 3 is currently not in use. 

The application programmer using partition 1 has just produced a load 
module named TESTPROG, which he now wishes to test. The 
TESTPROG load module just produced is stored on volume EDX002. 
An earlier version of TESTPROG resides on volume EDX003. The 
programmer Inadvertently loads the old version of TESTPROG, which 
goes into execution. 
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> |$L TESTPR0G,EDX003 



TESTPROG lOP, 13:10:27, LP = 5F00 

Figure 14-4. 1st load 

The programmer soon realizes the wrong TESTPROG has been loaded, 
and without terminating the program, presses the ATTN key and 
requests the load of the new version of TESTPROG, this time using the 
proper volume. 



> $L TESTPROG, EDX002 



TESTPROG 12P, 13: 12:00, LP = 6900 

Figure 14-5. 2nd load 

The new version of TESTPROG begins execution. The program 
enqueues for the loading terminal, and before a DEQT is issued, a pro- 
gram logic error causes an execution loop. The ATTN key produces 
no response, because the requesting terminal is enqueued. The pro- 
grammer cannot, therefore, cancel ($C) either TESTPROG from this 
terminal. If the system were re-IP Led to recover, the production job 
running in partition 2 would have to be terminated, a possibility that 
may or may not be practical. 

Since the TTY device assigned to partition 3 is not in use, the pro- 
grammer moves to the TTY, and wanting to know what partition it is 
assigned to, enters the following; 



> 



$A 



PROGRAMS AT 13:13:14 
IN PARTITION #3 NONE 

Figure 14-6. P3$A 

The TTY is still assigned to partition 3, the IPL configuration specified 
in the TERMINAL statement defining the TTY terminal. No programs 
are presently active in partition 3. 

The programmer now switches the TTY to partition 1, and displays 
the programs there. 



> $CP 



PARTITION # ? m 
> 



$A 



PROGRAMS AT 13:14:46 
IN PARTITION #1 
TESTPROG 5F00 
TESTPROG 6900 

Figure 14-7. PI $A 
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Both versions of TESTPROG are displayed, along with their load points 
in partition 1 . The next step is to cancel the looping program, freeing 
up the enqueued $SYSLOG. 



> 



$C 



PGM NAME: TESTPROG 



LOAD POINT = 6900 



TESTPROG CANCELLED AT 13:15:12 
> 



$C 



PGM NAME: TESTPROG 



TESTPROG CANCELLED AT 13:15:59 
> 



$CP 



PARTITION # ? H 

Figure 14-8. "$C" 



The system prompts for load point on the first cancel, because two 
programs of the same name are in the partition. If the first program 
cancelled were the one which had the 4979 enqueued, the operator 
could then go back to the 4979, which would now respond to the ATTN 
key, and terminate the remaining version of TESTPROG normally, or 
cancel it, if necessary. In this example, he continues with a cancel of 
the other TESTPROG from the TTY. Note that no load point is 
required when only one program of that name is active in the partition. 

The TTY is then switched back to partition 3. I F this is not done, 
future operator commands, including $L, issued from the TTY would 
still apply to partition 1 . 

Note: $A ALL could have been used to display all partitions. $A was 
used to show the use of the $CP command. 



SYSTEM UTILITY PROGRAMS -INTRODUCTION 



In this section, the Event Driven Executive utility programs are dis- 
cussed under five major groups: 

1. Data Management/Maintenance Utilities 

2. Terminal Utilities 

3. Miscellaneous Utilities 

4. Program Preparation Utilities 

5. Utilities supporting system facilities and features not covered in 
this study guide. 
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Groups 1 through 4 include all of the most commonly used utility pro- 
grams pertaining to facilities or topics discussed in this study guide. For 
the most part, Event Driven Executive utilities are self-tutoring; entry 
of a "1" in response to a COMMAND (?): prompt will result in a display 
of all the command options available for that utility. Most command 
options are self-explanatory. Discussion of the simpler utilities will be 
limited to an illustration of the command options available (terminal 
output resulting from "?" command response), with a brief explanation 
of complex/obscure commands if required. Numerous examples of 
actual utility operation may be found in the reading assignments, and 
are not duplicated here. 

Some utilities have specialized and/or seldom used functions. Where 
this is the case, utility operation is discussed and illustrated in full. 

Group 4 consists of those utilities required for source program prepar- 
ation. Some are covered in this section, but for most, discussion is 
reserved for "Section 16. Program Preparation Using $EDXASM." 
Group 5 are those utilities supporting communications/graphics 
facilities, topics which are not addressed in this course. Discussion 
is limited to a brief description; no illustrations are provided, and 
instead of a READING ASSIGNMENT, there will be a READING 
REFERENCE, often in a system reference manual (SRL) not listed 
as one of the three manuals required for completion of this course. 



DATA MANAGEMENT/MAINTENANCE UTILITIES 
$DASDI 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Utilities, Operator's Reference, Messages and Codes (SC34-1703), 
"$DASDI Utility Program." 

Before Event Driven Executive logical volumes can be defined on disk 
or diskette, the magnetic surface of the disk/diskette must be prepared 
for use. This preparation consists of a surface analysis, wherein test 
data is written, and then read back and checked for accuracy. If 
defective sectors are found, they are flagged, and alternates are assigned. 
Sector addresses are written, and in the case of diskettes, 128 byte 
sectors are established. 

The Event Driven Executive utility used for disk/diskette surface prepar- 
ation is $DASDI. Figure 14-9 is the prompt/response sequence resulting 
from initialization of a diskette mounted on a 4966 Diskette Magazine 
Unit. 
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> |$L $DASDI 



$DASDI 7P,05:30:55, LP= 7600 
DIRECT ACCESS DEVICE INITIALIZATION 
DISK INITIALIZATION OPTIONS: 

0=CREATE STAND-ALONE DUMP DISKETTE 4964/4966 
1=4964, 4966 DISKETTE INITIALIZATION 
2=4962 DISK INITIALIZATION 
3=4963: DISK INITIALIZATION 
4=EXIT DISK INITIALIZATION 
ENTER DISK INITIALIZATION OPTION: [T] 

it********************************************* 

* DISKETTE FORMATTING PROGRAM * 

* IF FORMATTING IS IN PROGRESS, DO NOT * 

* CANCEL ($0 THIS PROGRAM. INSTEAD, * 

* ENTER ATTN/$IDSKETT TO FORCE TERMINATION. * 
********************************************** 

ENTER DISKETTE ADDRESS IN HEX EZI 

INITIALIZE FOR USAGE WITH THE IBM EVENT DRIVEN EXECUTIVE? [3 
DEVICE VARIED OFFLINE 

** WARNING ** 
FORMATTING WILL DESTROY ALL DATA ON THE DISKETTE IN SLOT 1. CONTINUE? 
IBMEDX VARIED ONLINE 

FORMATTING COMPLETE 

LOAD $INITDSK? 

Figure 14-9. Diskette surface preparation 

The 4966 has a capacity of 23 diskettes, 2 magazines of 10 diskettes 
each, plus three slots for individual diskettes. The three individual slots 
are the first three slots in the device. $DASDI operates on slot 1 only; 
any diskette on which surface preparation is to be run must first be 
mounted in slot 1. 

After surface analysis is complete, $DASDI writes the volume label 
IBMEDX, on the diskette. The next step after preparing a diskette 
surface is usually to create a logical volume for use with the Event 
Driven Executive. Logical volumes are created (directories established, 
etc.) with the $INITDSK utility. $DASDI therefore gives you the 
option of going directly into $INITDSK execution, without having to 
end $DASDI and issue the $L command for $INITDSK yourself. 

Surface analysis, sector address writing, and alternate sector assign- 
ment for 4962 and 4963 disks is done at the factory. When you 
receive your disk unit it is ready to go; you do not have to run 
$DASDI before running $INITDSK. 

While running your system (after logical volumes have been created), 
it is possible that a sector on disk may go bad. if this occurs, $DASDI 
can be used to flag the defective sector and assign an alternate, 
without disturbing the rest of the data on the disk. 
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$INITDSK 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$INITDSK 
Utility Program." 

$INITDSK is the utility program used to establish libraries on Event 
Driven Executive logical volumes. Figure 14-10 illustrates the initial 
prompt/response sequence when $INITDSK is loaded. 



> I$L SINITDSK 

$INITDSK 58P, LP= 8C00 

COMMAND (?): ? 

ID - INITIALIZE DEVICE 

AV - ALLOCATE VOLUME 

AF - ALLOCATE FIXED HEAD VOLUME 

SV - SPLIT VOLUME 

IV - INITIALIZE VOLUME 

II - INITIALIZE IPL TEXT 

VV - VERIFY VOLUME 

LV - LIST VOLUMES 

DV - DELETE VOLUME 

EN - END PROGRAM 

Figure 14-10. $INITDSK options 

Figure 14-1 1 illustrates the step by step procedure of using $INITDSK 
to set up a disk prior to installing an EDX System. The ID command 
creates a volume directory for a disk at address 03. Three volumes 
(EDX002, ASM LIB and EDX003) are allocated. Directories are 
created for each volume capable of handling 500 data sets each. A 
nucleus ($EDXNUC) is allocated in EDX002 and IPL text is written 
pointing to $EDXNUC as the supervisor to be loaded at IPL time. 
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$INITDSK 



58P, LP= 8D00 



COMMAND (?): |ID 3 



INITIALIZE DEVICE WILL DESTROY ALL DATA 
CONTINUE? 13 
DISK INITIALIZED 
ALLOCATE A VOLUME? [T| 



VOLUME: EDX002 



SIZE IN RECORDS: ilOOOOl 

EDX002 ALLOCATED 

INITIALIZE THE VOLUME JUST ALLOCATED? 

MAXIMUM NUMBER OF DATASETS: 



500 



DO YOU WANT WRITE VERIFY FOR THIS VOLUME? [N] 

ALLOCATE $EDXNUC? [Y] 

VOLUME INITIALIZED 

INITIALIZE IPL TEXT? [Y] 

IPL TEXT WRITTEN 

ALLOCATE ANOTHER VOLUME? 

VOLUME: 



ASMLIB 



m 



10000 



SIZE IN RECORDS: 

ASMLIB ALLOCATED 

INITIALIZE THE VOLUME JUST ALLOCATED? 

MAXIMUM NUMBER OF DATASETS 



500 



DO YOU WANT WRITE VERIFY FOR THIS VOLUME? 
ALLOCATE $EDXNUC? [n] 
VOLUME INITIALIZED 
ALLOCATE ANOTHER VOLUME? 
VOLUME: 1EDX003 



m 



15880 



SIZE IN RECORDS 

EDX003 ALLOCATED 

INITIALIZE THE VOLUME JUST ALLOCATED? [Y] 

MAXIMUM NUMBER OF DATASETS: 



500 



DO YOU WANT WRITE VERIFY FOR THIS VOLUME? JN] 
ALLOCATE $EDXNUC? 
VOLUME INITIALIZED 



COMMAND (?): lENI 
$INITDSK ENDED 

Figure 14-11. Using $INITDSK 
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$DISKUT1 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$DISKUT1 
Utility Program." 

> |$L $DI$KU"fl] 

$DISKUT1 37P, LP= 6300 

USING VOLUME EDX002 

COMMAND (?):!?] 

AL ALLOCATE SPACE 

CV CHANGE VOLUME 

DE DELETE MEMBER 

EN END THE PROGRAM 

LA *— LIST ALL (DS/PGM) 

LACTS * LIST ALL (CTS MODE) 

LD *— LIST DATA SETS 

LDCTS * LIST DATA SETS (CTS MODE) 

LM LIST 1 MEMBER 

LP *— LIST PROGRAMS 

LPCTS * LIST PROGRAMS (CTS MODE) 

LS LIST SPACE 

LV *— LIST THROUGH VOLUMES (DS/PGM) 

LISTP - DIRECT LISTING TO $SYSPTR 

LISTT - DIRECT LISTING TO TERMINAL 

RE RENAME A MEMBER 

*~- PREFIX (OPTIONAL) 
COMMAND (?): 

Figure 14-12. $DISKUT1 commands 

$DISKUT1 provides many of the most frequently required DASD 
storage management furlttions. Those functions annotated as 
PREFIX (OPTIONAL) indicate that if a 1 to 8 character text string is 
entered with the command, the command will apply to those members 
whose name begins with that text string. 

When the utility is first loaded, commands apply to the IPL volume, 
but may be switched to other volumes with the Change Volume (CV) 
command. The only exception is the List Through Volumes (LV) 
function, which lists the data sets and programs in all volumes currently 
online, without requiring entry of CV to switch from one volume to 
another. 
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$DISKUT2 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$DISKUT2 
Utility Program." 



> %l SDISKUrZ 

$DISKUT2 46.P,06:57:29t LP= 0000 

USING VOLUME tD<002 

CUI^MANO(?): ? 

CO - CLEAR DATA SET 

CV - CHANGE VOLUME 

DP - DUMP OS OR PG^^ ON PRINTEK 

OU - DUMP OS OR PG?^ ON CONiSOLE 

(-CA- WILL CA.MCEL) 

PA - PATCH OS OR PGM 

SS - SET PROGRAM STORAGE PARM 

LP - LIST 03 ON PRINTER 

LU - LIST OS ON CONSOLE 

PL - LIST LOG QH PRINTER 

LL - LIST LUG ON CONSOLE 

EN - 6N0 PROGRAM 

COr--MANO(?) : 

Figure 14-13. $DISKUT2 commands 

In addition to the functions listed in Figure 14-13, all of which normally 
operate on symbolically named data or program members, $DISKUT2 
has the capability to operate on absolute record numbers within a 
volume. If, when prompted for data set name, the operator enters the 
special system name $$EDXVOL, the operation will then be directed 
to absolute record numbers, rather than symbolic data/program mem- 
ber names, with record number 1 being the first record in the volume. 

Similarly, if the special system name $$EDXLIB is entered, absolute 
record numbers will be used, and the first record in the directory will 
be considered record 1 . For most volumes, $$EDXLIB and $$EDXVOL 
will both reference the same record, as libraries on volumes usually 
begin at the first record in the volume. 

Figure 14-14 illustrates the use of the absolute record capability. 
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> |$L $DISKUT2| 

$DISKUT2 46P, LP= 6300 

USING VOLUME EDX002 



COMMAND^ 


>): DU $$EDXLIB 


0036 
0000 
D5E4 
7C3C 
E3D9 
0563 
E4E3 
1158 
E4E3 
4AC8 
I.I7B9 
0C60 

racs 

0000 
C5E2 
1B9C 


0001 
0000 
C340 
0230 
C3C5 
0000 
F140 
0000 
F240 
0000 
C5E2 
0000 
E2F0 
0000 
E340 
4040 


003C 
0000 
003C 
0000 
013C 
0081 
0144 
01C5 
015A 
07A6 
01B5 
0152 
01C5 
0000 
01D5 
02B0 


351C 
0000 
013B 
0000 
0143 
0000 
0159 
0000 
01B4 
0000 
01C4 
0000 
01II4 
0000 
01F6 
0000 


oooooooooooooooo 

OOOOOOOOOOOOOOOO 

oooooooooooooooo 
oooooooooooooooo 


0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 


|:|i: 






$$EDXLIB IS A [ 
FIRST RECORD 
LAST RECORD 
FIRST WORD 
WORDS / RECORD 
(D)EC OR HE(X) 

RECOFv'D 1 
1 


3A- 

7V< 


FA 

\ 

1 

I 

128 

K 

fO 


SET 

73C0 
0000 
C4E7 
0000 
E2C3 
0000 
E2C3 
0000 
E2C3 
0000 
II6D4 
0000 
r9F7 
0100 
D6E3 
0000 




9 


0000 
5E<C5 
0003 
5BC2 
0003 
5EC2 
0003 
5BC2 
0003 
5BC3 
0003 
5BF4 
0001 
5BC9 
0003 


1 






17 


I$EDXNUC 
1 . « « . (^ « . . 






25 






33 


1 $BSCTRCE 
1 






41 






49 


I$BSCUT1 

1. 

1 $BSCUT2 

1 CH.. 

1 $COMI-'F<ES 
1 -. . 






57 
65 
73 
81 
89 


.£ 

1 


. D . . . . 1 


97 
105 


I$4978CS0 
1 


.E 


. M 1 


113 
121 


i$IOTEST 
1 


,N 


.6 1 



DUMP COMPLETE 
ANOTHER AREA? 

Figure 14-14. Absolute record capability 



Using the special system name $$EDXLIB, the operator is able to dis- 
play the first record in the directory of volume EDX002. 
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$COPY 



READING ASSIGNMENT: IBM Serles/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$COPY 
Utility Program." 



> %L iCJPY 

^COPY 33Pf06:54:Zlf LP= uOOO 

CO''\'^'iANO {?): ? 

CO - CO'-^Y .-^ATA ScT 

CV - COPY yni-J^E 

;vr _ (20'>Y FROM 3^5IC ^XCHANOl 

v.E - CCPY TJ 3A'~jIC EXCHAKGr- 

(-CA- .JILL CANCEL) 
?::;\; - L*fO PRJGKA.M 
CG^'M.'^^^iD (?): 

Figure 14-15. $COPY commands 

When using $COPY to copy library members, the target member must 
already exist (allocate using $DISKUT1), and must be of the same 
organization as the source member. When copying program members, 
the target member must be of equal or greater size than the source mem- 
ber. When copying data members an entire member may be copied, 
or only a selected number of records (partial copy) may be copied. 
If the entire member is to be copied, the target data member must be 
equal to or larger than the source. If doing a partial copy, the target 
member need not be as large as the source, but must have enough 
space following the starting target record number to accommodate 
the number of records being copied from the source number. 

The Copy Volume (CV) command allows entire volumes to be copied, 
providing a volume back-up capability. A disk volume may be 
copied to another disk volume, a diskette volume to another diskette 
volume, or a diskette volume to a pre-allocated data set of appropriate 
size (949 records for Diskette-1, 1924 for Diskette-2) on disk. (For 
disk volume to diskettes, see $MOVEVOL later in this section.) Note 
that copy volume operations do not add the members in a source 
volume to the target volume; the original contents of the target volume 
are replaced, including the directory. 
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$C0PYUT1 



If you have two or more 4964 Diskette Units, or a 4964 and a 4966 
Diskette Magazine Unit, diskette volume copies between diskette 
devices are possible. If you have a single diskette drive and a disk, 
diskette volume copies may be performed using the following procedure: 

1. Allocate a target data set on disk of 949 records (Diskette 1 ) or 
1924 records (Diskette 2) 

2. Using the CV command, copy the diskette volume to the disk 
data set 

3. Mount the target diskette on the diskette device and vary 
(> $VARYON) online 

4. Using the CV command, copy the contents of the disk data set 
to the target diskette 

If you have a single 4966 Diskette Magazine Unit and a disk, the 
above procedure is also recommended. Diskette volume copies between 
different slots of a 4966 are allowed, but are very time consuming due 
to the slowness of the magazine diskette selection mechanism. 

$COPY, like $DISKUT2, has an absolute record capability, using the 
special system names $$EDXLIB and $$EDXVO.L. This allows copying 
of any record relative to the beginning of a volume ($$EDXVOL) or 
relative to the beginning of a library ($$EDXLIB). This capability 
might be used, for example, when copying one diskette volume to 
another. The CV function of $COPY does not copy the first cylinder 
on diskette. If the source diskette were an IPL volume (has IPL text 
and $EDXNUC), the IPL text, contained in the first record of the 
first cylinder, would not be copied to the target diskette, and the 
target diskette volume, although containing a supervisor in $EDXNUC, 
would not be able to load the supervisor when the IPL key was pressed. 

To copy the IPL text to the target diskette, the CD function of $COPY 
can be used, with $$EDXVOL specified as the data set name, and 
record 1 specified as the first and last record to be copied. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$C0PYUT1 
Utility Program." 

$C0PYUT1 is used extensively in system installation and maintenance 
activities, such as installing the various system libraries received from 
PID, and in applying PTF fixes distributed on diskette, $C0PYUT1 
differs from $COPY in that operations are performed on entire mem- 
bers only; partial copies are not allowed, nor are volume copies or 
absolute record operation. 
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CM— COPY MEMBER FROM SOURCE TO TARGET 

MULTIPLE COPY COMMANDS 

CALL— COPY ALL MEMBERS FROM SOURCE TO TARGET 
CAD— COPY ALL DATA MEMBERS FROM SOURCE TO TARGET 
CAP— COPY ALL PROGRAMS FROM SOURCE TO TARGET 

CG COPY ALL MEMBERS STARTING WITH TEXT FROM SOURCE TO TARGET 

CNG— COPY ALL MEMBERS NOT STARTING WITH TEXT FROM SOURCE TO TARGET 

END OF MULTIPLE COPY COMMANDS 

SQ SET PROMPT MODE FOR ALL MULTIPLE COPY COMMANDS 

NQ— RESET PROMPT MODE FOR ALL MULTIPLE COPY COMMANDS 

— CA— WILL CANCEL MULTIPLE COPY COMMANDS 

CV— CHANGE SOURCE AND TARGET VOLUMES 

ROLLON -SET SCREEN = NO PAUSE 

ROLLOFF -RESTORE PAUSE CHARACTERISTICS 

EN— END PROGRAM 

? —HELP 

Figure 14-16. $C0PYUT1 commands 

This Utility will copy data or program members from a source volume 
to a target volume, and: 

1. Will delete a member from a target volume, if a member exists 
with the same name as the member being copied from the 
source volume 

2. Will allocate a member on the target volume of the same size 
and data organization as the source member — preallocation 
not required 

3. Will copy multiple members with a single command (all, all data, 
all program, generic, non-generic), with or without a prompting 
pause 
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> |$L $copyutT 

$C0PYUT1 48P, 00:00: 14, LP= 6000 

***WARNING MEMBERS ON TARGET VOLUME WILL BE OVERWRITTEN 



*•• 



THE DEFINED SOURCE VOLUME IS EDX002, OK? NO 



ENTER NEW SOURCE VOLUME: EDX003 



THE DEFINED TARGET VOLUME IS EDX002, OK? YES 



MEMBER WILL BE COPIED FROM EDX003 TO EDX002 OK? lYESi 
COMMAND (?) 



CG 



ENTER GENERIC TEXT: |AREC 
ARECPGMl COPY COMPLETE 
ARECPGM5 COPY COMPLETE 
ARECPGM3 COPY COMPLETE 

COMMAND (?): 

Figure 14-17. Generic copy 



300 RECORDS COPIED 

100 RECORDS COPIED 

50 RECORDS COPIED 



Figure 14-17 is an example of a generic copy without a prompting 
pause. The warning message indicates that existing members with the 
same name as any of those being copied will be deleted. 



$IVIOVEVOL 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$MOVEVOL 
Utility Program." 

$MOVEVOL is a dump/restore utility, used to dump entire disk 
volumes to diskette or restore disk volumes from diskette, where the 
volumes may span several diskettes. 

A dumped volume consists of a control diskette containing the volume 
directory and control information, and as many data diskettes as are 
required to hold the rest of the information in the volume. See the 
reading assignment for information on creating the control and data 
diskettes, and for examples of $MOVEVOL operation. 



$COMPRES 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$COMPRES 
Utility Program." 

During normal system usage, data sets In Event Driven Executive 
volumes will be deleted, leaving "holes" (free space) between members. 
The $COMPRES utility consolidates all available free space within an 
Event Driven Executive volume into one contiguous area. 
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$TAPEUT1 



> 1$L COMPRES 



$COMPRES 17P, 00:32:48, LP= 6900 f~^ 



COMPRESS SYSTEM LIBRARY 
WARNING! SHOULD BE RUN ONLY WHEN 
NO OTHER PROGRAMS ARE ACTIVE 



VOLUME LABEL = EDX003 



COMPRESS LIBRARY ON EDX003? lYES 



DIRECTORY HAS BEEN SORTED BY MEMBER IN ASCENDING ORDER, 

$EDXNUC COPIED 

DATAl COPIED 

PROGl COPIED 

PR0G2 COPIED 

THE LIBRARY IS COMPRESSED. 



ANOTHER VOLUME? I NOI 
$COMPRES ENDED AT 00:34:39 

Figure 14-18. $COMPRES example 

The example shows compressing the members in volume EDX003. 
Never compress a volume when any other program is active. You can 
determine what programs are active by using the $A operator command. 
If the compress was performed on the volume that contained the super- 
visor you IPLed from, and if the $LOADER program's location was 
changed, you must re-IPL. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$TAPEUT1 
Utility Program." 
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> $L $TAPEUT1 

$TAPEUT1 20P, 01:21:58, LP= 0000 

COMMAND (?): |T| 

CD COPY TAPE DATASET 

CT CHANGE TAPE ATTRIBUTES 

DP DUMP TAPE 

EN END $TAPEUT1 

EX EXERCISE TAPE 

IT INITIALIZE TAPE 

LT LIST TAPE DRIVES AND ATTRIBUTES 

MT MOVE TAPE 

RT RESTORE DISK/VOL FROM TAPE 

ST SAVE DISK/VOL ON TAPE 

TA ALLOCATE TAPE DATASET 

COMMAND (?): 

Figure 14-19. $TAPEUT1 options 

$TAPEUT1 provides many of the most frequently required tape man- 
agement functions. When invoi<ed, the utility displays information 
about tapes defined to the system. The functions provided allow a 
user to initialize taxes, allocate and copy tape data sets, and print tape 
records as well as providing a save/restore facility for disk devices. 



TERMINAL I/O UTILITIES 



$TERMUT1 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$TERMUT1 
Utility Program." 

This is a general purpose terminal utility, used to perform several 
terminal-related functions. 
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> $L $TERMUT1 



$TERMUT1 19P, 01:12:29, LP= 5F00 

*** TERMINAL CONFIGURATOR *** 

COMMAND(?): [?] 

LA — LIST TERMINAL ASSIGNMENTS 

RE -- RENAME 

RA -- REASSIGN ADDRESS 

RH — REASSIGN HARDCOPY 

CT -- CONFIGURE TERMINAL 

EN -- END PROGRAM 

COMMAND(?): 

Figure 14-20. $TERMUT1 options 

The current terminal name, hardware address, and terminal type may 
be displayed using the LA (list assignment) function. 



> $L STER'^UTl 

STERVUTl 190, 03:56:41* LP- 0000 

««« TERMINAL CONFIGURATOR *** 

CaMMANC(?>: LA 

xAME ADORPSS TYPE PARTITION HARDCOPY 



^^.^ 



===> iSYSLGG 


04 


4979 


2 


SSYSPRTR 


DSPLYl 


06 


4978 


3 


SSYSPRTR 


SSYSLOGA 


00 


TTY 


1 




SSYSLOGb 


Ott 


ACCl 


2 




LINEPRTR 


21 


4973 


1 




tSYSPRTR 


01 


4974 


1 





(3101 BLOCK MODE) 



COMMANn(?): EN 

STERMUTl ENOFn AT 03:57:24 

Figure 14-21 . LA 



Terminals may be renamed, using the RE function. For instance, if 
the 4973 printer in Figure 14-21 were mistakenly referenced (ENQT) in 
a program as LINPRNTR the name could be temporarily changed from 
LINEPRTR to LINPRNTR to test the program, and then changed back. 

COMMAND(?): [RE] 



OLD, NEW TERMINAL NAMES: JLINEPRTR LINPRNTR 
COMMAND(?): 



Figure 14-22. RE 
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$TERMUT2 



Terminal hardware addresses (RA), hardcopy device/hardcopy PF key 
designations (RH), and page format configuration parameters (CT) 
may all be reassigned using $TERMUT1. Reassignments remain in 
effect until reassigned again, or until the next I PL, which will cause all 
terminals to revert to the assignments in the TERMINAL system 
configuration statements. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$TERMUT2 
Utility Program." 

4978 Displays have a control store and an image store, which are 
loaded from disk or diskette data sets. At IPL, the system auto- 
matically loads all 4978s with the control store data set $4978CS0 
and the image store data set $4978150. These may be the standard 
system-supplied data sets, or may be user-created control/image 
store data sets that have been renamed $4978CS0 or $4978180. 



> TL STLH^-!IJT2 



ETFR'^'UTZ 



3^p, )6: 5 d: 56, LP= JOOi 



CGMM^^JO (?) : rn 

AO - i\SSTC,\ DEFINt KEY 

C - Ct-'ANGE KEY OEFINITIGM 

E - !zNl t^K'QC>RA'^ 

LC - Lr.^:> CC\'T'^OL STDf^E 

L I -- LOAD I MAGE STORE 

SC - SAVE CO\rP.CL STC'^E 

SI - SAVE HUGE STJi^E 

RE - REST IRE ^9 74 T') STO. bn CHAR. SET 

CC'^MASD ( ? ) : 

Figure 14-23. $TERMUT2 options 

After IPL, $TERMUT2 can be used to load a control or image store 
from user-defined control/image data sets (LC and LI commands), 
or to read the control or image store in a display, and write it to a 
user-allocated data set (SC and SI commands). Control store data 
sets require 16 records, and image store data sets, 8 records. 

The 4978 hardware supports the DEFINE function, which allows keys 
to be defined with special character strings that have meaning to a 
particular application or job. In order to define a key with special 
characters, DEFINE mode must be entered. This is accomplished by 
pressing the DEFINE key on the 4978 keyboard. 
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Assuming a standard 4978 keyboard Is installed, the $4978CS0 control 
store supports the keyboard shown in Figure 14-24. (The unshaded 
keys are those that will produce hardware interrupts.) 



f 








HEEEi 



SHIFT 



omomm 



REP 



SHIFT 



REP 















ERASE 


EOS 
EOF 


E 
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T 
E 
R 


INS 
MODE 


DEL 
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HOME 


K- 
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*- 
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00 


•»■ 


- 


7 
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4 


5 


6 


1 


2 


3 








Figure 14-24. 4978 keyboard, RPQ D02056 



As can be seen, there is no key permanently designated as the 
DEFINE key. However, using the AD command of $TERMUT2, 
you may assign a key of your choice as the DEFINE key. 

Figures 14-25 and 14-26 are taken from the General Information 
manual for the 4978 keyboard (RPQ D02056). Similar charts are 
in the General Information manuals for whichever keyboard you 
have Installed. 

In Figure 14-25, each key position is assigned a reference number. 
Figure 14-26 Is the first page of several which list the hex scan 
code, function ID code, local function code, and interrupt code 
which comprises the control store Information for each key. The 
identifying numbers on the keys in Figure 14-25 correspond to the 
key position numbers on the chart In Figure 14-26. 
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Figure 14-25. Keyboard reference assignments 
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Control Store Data 


Downshift - Unshifted 


Upshift - Shifted 


K 

e 

V 

P 


Scan code 




K 

e 

y 
p 


Scan code 






Function ID code 




Function ID code 




Cliaracter/local function code 




Character/local function code 




s 
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t 
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Interrupt code 


Key top 
symbol 


o 
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Interrupt code 


Key top 
symbol 




Character image table 
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Figure 14-26. Control store data 
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In Figure 14-24, assume you want to make the key at Q the 
DEFINE key. In Figure 14-25, that key position has a reference 
number of 66. In Figure 14-26, the operator is prompted for the scan 
code of the key to be assigned as the DEFINE key. On Figure 14-26, 
the scan code for key position 66 is hex 20. After the scan code and 
terminal name have been entered (Figure 14-27), $TERMUT2 reloads 
the control store of the display, with key position 66 assigned as the 
DEFINE key. 



COMMAND (?): \M 

ENTER SCAN CODE OF THE KEY TO BE ASSIGNED 

AS THE DEFINE KEY (HEX): |20] 
ENTER TERMINAL NAME (CR OR * = THIS ONE): IDSPLYll 

Figure 14-27. AD command 

Back on Figure 14-24, the operator presses the DEFINE key at B 
key is the key which will be redefined. Assume the operator wishes 
to redefine Program Function Key 1, and presses it ( |3 on Figure 
14-23). Now all key depressions, until the DEFINE key is again 
depressed, will be assigned to PF1 . 

The operator enters the character string $L $FSEDIT EDITWORK, 
and then presses one of the two ENTER keys. He or she then presses 
the DEFINE key again, ending the redefinition of PF1, and taking the 
4978 out of DEFINE mode. 

The character string entered is a request to load the text editing utility 
program $FSEDIT, along with the name of a text edit work data set, 
EDITWORK. 

Counting the depression of the ATTN key required to get the > prompt, 
and the ENTER key depression following the load request, this line of 
text normally takes 21 keystrokes to enter into the system. Now that 
PF1 has been redefined as this line of text, only two keystrokes are 
required; the ATTN key, resulting in the > prompt, followed by PF1, 
which enters $L $FSEDIT EDITWORK and the ENTER key, which 
was also part of the redefinition string. 

For normal terminal usage, an active DEFINE key is not desirable. 
If it is depressed inadvertently, altering of the control store will result. 
In Figure 14-28, the C command is used to change key position 66 
back to its original control store configuration, using the chart in 
Figure 14-26 to supply the codes. 

COMMAND (?):[£] 

ENTER TERMINAL NAME (CR OR * = THIS ONE): IDSPLYll 



ENTER SCAN CODE OF THE KEY TO BE REDEFINED (HEX): |20 

ENTER FUNCTION ID (HEX): |20] 

ENTER CHARACTER/FUNCTION CODE (HEX) 

ENTER INTERRUPT CODE (HEX): B 

ANOTHER KEY? M 



Figure 14-28. C command 
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At the conclusion of the C operation, the control store of 4978 
DSPLY1 still has PF1 defined with the text editor load request 
character string, but with no DEFINE key designated. The SC 
operation in Figure 14-29 reads the control store, and stores it in a 
16 record data set named 4978EDIT, which must be preallocated. 
Any time a user desires a keyboard with PF1 redesignated as a text 
editor load request, the LC command of $TERMUT2 can be used to 
load the control store from 4978EDIT. 



COMMAND (?) , 

SAVE DATA SET (NAME, VOLUME) : 14978EDIT1 

ENTER TERMINAL NAME (CR OR * = THIS ONE): IDSPLYI 



COMMAND (?): [END 



$TERMUT2 ENDED AT 01:27:44 



Figure 14-29. SC command 



$TERMUT3 



$PFMAP 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$TERMUT3 
Utility Program." 

$TERMUT3 is used to enter a text message and send it to another 
named terminal. See the reading assignment for examples and operating 
instructions. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$PFMAP 
Utility Program." 

When a WAIT KEY operation is terminated by pressing a Program 
Function key, an identifying code for the key is placed in taskname+2, 
which may be examined by user instructions (see the topic ".STATIC 
SCREEN CODING EXAMPLE" in "Section 11. Terminal I/O"). For 
a 4979 terminal, PF keys PF1 through PF6 return identifying codes of 
1 through 6. Since only the ENTER key and the six PF keys present 
identifying codes, determining what code to check for is a simple matter. 

The 4978 keyboard has a great many more interrupting keys than does 
the 4979, and determining which key is associated with a particular 
identifying code is, therefore, more difficult. In fact, by using the 
DEFINE feature, even the normal alphameric data entry keys and 
cursor positioning keys may be redefined as interrupting keys. 

When $PFMAP is loaded, it displays, in both decimal and hexadecimal 
form, the identifying code returned by any interrupting key pressed 
while $PFMAP is in execution (with the exception of the ENTER key, 
which ends the utility). Using this utility, an application programmer 
can easily find out what code is associated with a particular key and, 
therefore, what to check for in taskname+2. 
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$FONT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$FONT 
Utility Program/' 

As already noted in the discussion of the $TERMUT2 utility, the 4978 
Display has both a control store and an Image store. The combination 
of Scan code. Function ID code. Character/local function code, and 
Interrupt code which is assigned to each key determines what function 
each key will perform if pressed. This function definition information 
is contained in the 4978 control store. 

One of the functions which may be assigned to a key is that of display- 
able character (Function ID code = 00). Each key defined as a display- 
able character key will have an EBCDIC code associated with it 
(character/local function code in control store), which will be generated 
when that key is pressed. 

The 4978 also has an image store, containing the bit patterns which, 
when interpreted by the hardware, result In the display of characters 
on the screen. Each character bit pattern is associated with an EBCDIC 
code. When, for example, the "^" key is pressed on the keyboard and 
a "^" appears on the screen, it is only because of the following 
circumstances: 

1. In the control store, the function ID code for that key position 
has been defined as 00, assigning that key as a dispiayable 
character, and the character/local function code is defined as 
the EBCDIC character code F1. 

2. In the image store, the bit pattern associated with EBCDIC F1 
will, when interpreted by the hardware, result in the display of 
the figure we recognize as the arable numeral 1. 

In the discussion of $TERMUT2, an example of the CHANGE KEY 
DEFINITION function was given, whereby control store key definitions 
could be altered. If, for example, the character/local function code for 
the 1 key were changed from EBCDIC F1 to EBCDIC C2, pressing the 
1 key would result in the display of the alpha character B, because the 
image store bit pattern associated with C2 Is B. 

Similarly, the bit patterns in the Image store may also be changed to 
alter the appearance of the characters displayed, or if desired, to create 
entirely new characters. $FONT is the utility program used to mani- 
pulate image store bit patterns. 

4978 image stores, like control stores, may be loaded from disk/diskette 
data sets. An image is 2K bytes in size, requiring a data set 8 records 
in length. 
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Figure 14-30. Allocate image store data set 



Allocation of a user image store data set is not a prerequisite to using 
$FONT. The system-supplied image store data set $4978150 can be 
used with $FONT. $4978180 is, however, automatically loaded to 
every 4978 supported by the supervisor at I PL, and modifications 
made will be reflected in all the displays, which may not be desired. 

When $FONT is loaded, the name of an image store data set must be 
supplied. If not supplied as advance input, as in Figure 14-31 , the 
operator will be prompted to enter it. 




Figure 14-31 . $FONT commands 
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The DISP command will display all 256 EBCDIC codes on the screen, 
along with the characters that are generated for each code by the 
associated bit patterns in the image store. If DISP were entered at 
this point, $FONT would display the image store in the image store 
data set MYIMAGE. Since MYIMAGE was just allocated, and does 
not yet contain an image table, a meaningless display would result. To 
acquire an image table to work with, a GET command may be entered 
to read an image table from a 4978. 




Figure 14-32. GET command 



The Utility now has an image table, and DISP can be used to display 
that table. 




Figure 14-33. Image table 
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The characters are displayed to the right of the EBCDIC codes with 
which they are associated. To illustrate how the bit patterns which 
generate these characters may be altered, assume that the operator 
wishes to alter the appearance of the character "T" by extending the 
ends of the crossbar at the top of the character downward. In Figure 
14-33, the character "T" is associated with EBCDIC code "E3." To 
modify or create a character, EDIT mode must be entered. Display 
mode is ended by pressing the ENTER key. The COMMAND (?): 
prompt will again appear, whereupon the operator can enter the 
EDIT command, which will cause the screen in Figure 14-34 to 
appear. 




Figure 14-34. EDIT mode (1) 

When EDIT mode is first entered, the cursor will be positioned just to 
the right of the CODE prompt on the bottom left of the screen. The 
utility is waiting for the operator to enter a character in the present 
cursor position, or to move the cursor to the right and enter an 
EBCDIC code between the parentheses. Assume the operator enters 
the character "T", and presses the ENTER key. 
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V 



Figure 14-35. EDIT mode (2) 



$FONT fetches the bit pattern for the entered character, displays the 
character image in the image grid at the right, and places the cursor in 
the top left-hand square of the 4 by 8 character image grid. The 
EBCDIC code for the character entered, "E3", is placed in the parentheses 
to the right of the CODE prompt. The character entered is also displayed 
below the character image grid (4978 only — not 4979). 

The cursor is moved about within the character image grid by the special 
PF key functions described on the screen. For example, pressing PF1 
one time will move the cursor forward (left- to-right, and top-to-bottom) 
across the grid one position, as shown in Figure 14-i36. 




Figure 14-36. EDIT mode (3) 
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PF2 will move the cursor backwards within the grid (right- to-left and 
bottom-to-top). PF3 will move the cursor from its present line down to 
the next line, and position it in the leftmost square of the new line. 
Figure 14-37 shows the screen after PF3, the "next line" key, has been 
pressed once. 




Figure 14-37. EDIT mode (4) 

At the outset of this exercise, the stated objective was to alter the 
appearance of the character "T" by extending ends of the top crossbar 
downwards. The cursor is now in a position to do that. By hitting 
PF4, the dot pattern in the first square of the second line is inverted, 
which extends the left end of the crossbar downwards. 




Figure 14-38. EDIT mode (5) 
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Notice that as modifications are made within the grid, they are reflected 
in the actual-size character below the grid. 

The cursor is now moved forward by pressing PF1 repeatedly until it is 
at the other side of the grid, as shown in Figure 14-39. 




Figure 14-39. EDIT mode (6) 



By pressing PF4 again, the other end of the crossbar is extended. 




Figure 14-40. EDIT mode (7) 
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The intended modification is now complete. Pressing the ENTER key 
results in the screen in Figure 14-41 . 




Figure 14-41. EDIT mode (8) 

At this point, the operator can "set" the character just composed into 
the image table. If ENTER is pressed, the modified T will replace the 
normal T. The operator also has the option of associating the 
modified T with a different key or EBCDIC code. If, for example, 
the operator typed an A on top of the T next to the SET prompt, 
and then pressed ENTER, the modified T would replace the character 
A. If the operator moved the cursor to the right, and overtyped the 
E3 within the parentheses with, for example, the EBCDIC code for 0, 
FO, the modified T image would replace that for 0. 

Assume the operator presses ENTER without altering the character or 
the EBCDIC code, resulting in the screen in Figure 14-42. 
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Figure 14-42. EDIT mode (9) 

The character has been set, the CODE prompt is again displayed, and 
the program is waiting for another character or EBCDIC code to be 
entered. The operator presses PF5, exiting EDIT mode, and reentering 
command mode. 

If you want to be able to load a modified image store to a 4978 at a 
future time, it must be stored on disk/diskette. The operator therefore 
enters the SAVE command. 



COMMAND(?): [?] 



DISPLAY TABLE 

ENTER EDIT MODE 

SAVE TABLE 

LOAD TABLE INTO DEVICE 

READ TABLE FROM DEVICE 

END PROGRAM 





Figure 14-43. SAVE command 
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Notice that no data set name is asked for when the SAVE command is 
entered. The table will always be saved in the data set specified when 
the utility was loaded; in this case, MYIMAGE. 

The only commands not yet exercised are PUT and END. Assuming 
that this utility session is being conducted on a 4978 named DSP LAY 1, 
a PUT to that device name will load this device with the altered image 
store, replacing normal "T" characters with new. 




Figure 14-44. PUT command 



This 4978 will continue to display the modified "T" until such time as 
its image store is again loaded with a different image table ($TERMUT2, 
$FONT, or IPL). 

Since the $FONT utility employs a static screen, this utility can only be 
used by 4978s or 4979s. 
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Figure 14-45. END 



MISCELLANEOUS UTILITIES 



$IMAGE 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes {SC34-1703), "$IMAGE 
Utility Program." 

$IMAGE is used to create formatted screen images for use with 
terminals that support static screen functions. The images (formatted 
screens) are stored in disk or diskette data sets for later retrieval by 
application programs. Stored images may also be retrieved by $IMAGE 
for modification/maintenance. 

In "Section 16. Program Preparation Using $EDXASM", the application 
program used as a program preparation example is the same program 
used in "Section 11. Terminal I/O" under the topic "STATIC SCREEN 
CODING EXAMPLE" (see Figure 11-43). In Section 16, the program 
is modified to retrieve a stored screen Image, rather than formatting the 
screen by executing instructions within the program. The following 
is a $IMAGE utility session In which the image that will be used by the 
modified program is created and stored. 
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A formatted screen created by $IMAGE is stored in a disk or diskette 
data set that must first be allocated by the user. The formatting 
information and text are stored in a special packed format to conserve 
space. A logical screen may be of any size from one character position 
up to an entire physical screen, and therefore the amount of space on 
disk or diskette required to store a given screen image will vary. For 
most logical screens, a data set two records in length will be adequate. 

The screen image that will be created in this utility session is shown in 
Figure 14-46 (same as that shown in Figure 11-31). Since it encom- 
passes an entire physical screen and contains several lines of text, a 
data set three records in length will be required to store it. 
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CHARACTER 
POSITIONS — ! 



/* 














^ 


ENTER 


KEY = 


PAGE 


COMPLETE 


PFl = DELETE ENTRY 1 


PF2 = 


DELETE ENTRY 2 


PF3 = 


DELETE 


ENTRY 


3 


PF4 = DELETE ENTRY 4 






CLASS 


name:: ^ 


- 






INSTRUCTOR MAMC: 






NAMt : 










STRfET: 
CITY ; 
STATl ; 






^•IAMl: 










STRrET: 
CITY ; 
STATE : 






NAME : 










STREET; 
CITY : 
STATE : 






NAME : 










STREET: 
CiTY : 
STATL : 







11111111 1 12222222222333333333344444444445555555555666666666677777777778 
-12345678901234567890123456789012345678901234567890123456789012345678901234567890 



Figure 14-46. Screen image 



Before beginning the $IMAGE utility session, a data set 3 records long, 
named VIDE01 is created using $DISKUT1. 



> $L $DISKUT1 



$DISKUT1 37P, 00:32:06, LP= 5F00 
USING VOLUME EDX002 



COMMAND (?): lAL VIDEOl 3 



DEFAULT TYPE = DATA - OK? [YES 
VIDEOl CREATED 



COMMAND (?): END 



$DISKUT1 ENDED AT 00:32:33 



Figure 14-47. Allocate image data set 
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Now the $IMAGE utility can be loaded, and the utility session began. 
Entering a "1" in response to the COMMAND (?): prompt results in a 
list of the $IMAGE commands. 



> 



$L $ I MAGE 



$IMAGE 76P, LP= 

COMMAND(?): H] 



8D00 



ATTR - DEFINE ATTRIBUTE CHARACTERS 

DIMS - DEFINE SCREEN DIMENSIONS 

EDIT - EDIT SCREEN FORMAT 

FTAB - DISPLAY FIELD TABLE 

HTAB - SET (HORIZONTAL) TABS FOR EDIT 

KEYS - DISPLAY USE OF PF KEYS 

NULL - DEFINE NULL CHARACTER 

PRNT - PRINT SCREEN IMAGE AND TABLES 

SAVE - SAVE SCREEN FORMAT(S) IN DATASET 

VTAB - SET (VERTICAL) TABS FOR EDIT 

END - END PROGRAM 



COMMAND(?): lATTR 



ATTRIBUTE CHARACTERS WITH MDT OFF: 

■) = % 
' ) = * 

') = $ 
■) = # 

DO YOU WISH TO DEFINE 

ATTRIBUTE CHARACTERS WITH MDT ON? M 



LOW INTENSITY (NOW IS 

HIGH INTENSITY (NOW IS 

BLINKING (NOW IS 

NONDISPLAY (NOW IS 



COMMAND(?) 
COMMAND(?) 
COMMAND(?) 
COMMAND(?) 



DIMS 24 80 



HTAB 31 



NULL / 



EDIT 



Figure 14-48. $IMAGE commands 



V_ 
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The ATTR command allows you to define the characters that define the 
attribute bytes for the 3101 I\/I2 screen. When creating a screen, the 
display mode of a field (protected or unprotected) can be set by pre- 
fixing the field with an attribute byte. In the example placing a $ in 
front of a field will cause that field to blink when the screen is dis- 
played. Attribute bytes are specified when defining protected or un- 
protected null fields. 

The DIMS command allows you to define the dimensions of the logical 
screen you are creating. The example shows a logical screen of 24 lines 
and 80 characters specified, which is equal to the entire physical screen. 

HTAB is the horizontal tab settings you wish to have in effect while you 
are creating the screen. If not entered, HTAB defaults to 10, 20, 30 etc, 
through 80. The example defines a single HTAB setting of 31. 

VTAB defines vertical tabs. The default is one vertical line for each 
vertical tab key depression. Since VTAB is not entered in this example, 
one-line vertical tabs will be in effect. 

The NULL command allows you to define the null character. When in 
EDIT mode, a null character is entered in each character position you 
want to display unprotected data in, or in which operator-entered data 
is to be accepted, when the completed screen is used by an application 
program. 

The KEYS command lists the functions of PF1, PF2, and PF3 (func- 
tions valid when EDIT mode is entered). 
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PF1— define protected fields 

PF2— define data fields (unprotected) 

PF3-return to COMMAND mode 

Figure 14-49. KEYS 

All of the commands listed in Figure 14-48 may only be entered in the 
COMMAND mode. The last command entered (Figure 14-48) is EDIT, 
which places the $IMAGE utility in EDIT mode. If an existing screen 
image were to be edited, the data set name and volume of that image 
would be entered with the EDIT command. Since this session is creat- 
ing a new screen, EDIT is entered without reference to a data set. 

When EDIT mode is entered, PF1, PF2, and PF3 have the functions 
listed in Figure 14-49. Before pressing any of the PF keys, the screen 
is entirely blank, and the cursor is In the lower left corner. 

The logical screen being created in this example contains both protected 
and unprotected data. The operator prompts on lines 1 and 2 are unpro- 
tected, and the rest of the prompts are protected (see Figure 14-46). 
When the completed screen is displayed, the unprotected areas will 
appear brighter than those that are protected, highlighting the prompts 
at the top of the image. 

When both protected and unprotected text is to appear on a screen 
created by $IMAGE, the protected data must be entered first. There- 
fore PF1 is depressed, signalling to the utility that protected fields are 
to be defined. The cursor now moves to the first available character 
position, which is line 0, space 0, in this example. 

As soon as either PF1 or PF2 is pressed, after entering EDIT mode, the 
function of PF1 and PF2 is redefined. PF1 is now used as the horizontal 
tab key, and PF2 as the vertical tab key. Since no text appears on line 
0, the vertical tab key PF2 is pressed, moving the cursor down to the 
first position of line 1. 

When defining the protected areas of a screen image, all characters 
entered, other than the null character, will be protected data. The 
operator prompts on lines 1 and 2 are supposed to be unprotected. 
Therefore, the actual text of the prompts cannot be entered until the 
data definition portion of this utility session, after all protected fields 
have been defined. However, since these areas of the screen will contain 
unprotected text, null fields must be established, so that when the 
unprotected data definition Is done, the text entered will be accepted. 
Figure 14-50 shows the screen after the null characters for the unpro- 
tected operator prompts at the top of the screen have been entered. 
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Figure 14-50. NULL entries 

Now the rest of the screen can be formatted. All areas of the screen not 
containing null characters will be protected when the screen is com- 
pleted. Note that any field meant to receive operator input when the 
screen is used must be defined using the null character. 

Figure 14-51 is the screen after all protected data has been defined. 
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r 
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4 


CLASS NAME: 1 1 II 1 1 1 1 II II II 1 1 


INSTRUCTOR NAME: 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 II II 


6 

7 
8 
9 


wmi:iiiiiiiiiiiiiiiiiiiiiii 


s-\KLU:iii nil mill mill nil iniiiiif/ I/I/I 
CITY •ninnnnnnnnnnnnnnimm 

STATE -.11111111111111111111111111111111111111 
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NAME://///////////////////// 
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Figure 14-51 . Protected entries 



Pressing the ENTER key takes the utility out of protected field defini- 
tion, back to EDIT mode (the situation as it was before a define pro- 
tected field or define data field decision was made). PF1 and PF2 again 
have the meanings printed out by the KEYS command (Figure 14-49). 
The ENTER key also causes the screen, as defined up to this point, to 
be displayed as pictured in Figure 14-52. 
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Figure 14-52. Partially completed image 

If the desired screen image were now complete, PF3 would be pressed 
to get back into COMMAND mode, so that it could be saved. In this 
example, however, there is still unprotected data to be defined, so 
PF2 is pressed. PF2 brings back the same screen image as in Figure 
14-51 , with the unprotected fields defined as null characters. 

The unprotected null fields in the operator prompt area at the top of 
the screen are now filled in. The other null fields are input fields that 
will be used when the screen is used by an application program, so are 
left undisturbed during screen creation. 

After all unprotected text is defined, the screen looks like that shown 
in Figure 14-53. 
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ENTER KEY = PAGE COMPLETE 
PF3 = DELETE ENTRY 3 
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PF4 



DELETE ENTRY 1 
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Figure 14-53. Complete image 
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$IOTEST 



When ENTER is pressed, the completed screen is displayed (Figure 
14-46). Any desired changes can be made by again pressing PF1 , for 
protected fields, or PF2, for unprotected ones. Assuming that the 
image is correct, the operator will press PF3 to return to COMMAND 
mode. 

PF3 will blank the screen, and prompt for a command entry. 



COMMAND(?): [SAVE VIDEQl 



COMMAND(?): END 



Figure 14-54. Save image 

The operator enters the SAVE command, followed by the name of the 
data set that was allocated for this purpose. The $IMAGE utility 
session is then ended. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$IOTEST 
Utility Program." 

$IOTEST is an exerciser program for the digital and analog sensor I/O 
features of the Series/1. The operator is prompted for various operating 
parameters, and the $IOTEST utility then repetitively executes the 
requested exercising operations. See the reading assignment for 
examples of the use of this program. 

The LD function will list all the hardware devices, and their hexadecimal 
addresses, for the Series/1 on which $IOTEST Is running. The LS 
command will list the hardware devices and addresses supported by the 
supervisor currently in operation. These two functions are particularly 
useful during system generation. By comparing the output produced 
by the LD and LS commands, the operator can easily spot devices 
attached but not supported, supported and not attached, or attached 
and supported, but assigned the wrong address. Use of these $IOTEST 
options is illustrated in "Section 15. System Installation." 
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$PREFIND 

READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$PREFIND 
Utility Program." 

If a program uses data sets or overlay programs (DS= and PGMS= 
keyword parameters in PROGRAM statement), the assembly process 
creates control blocks in the program header for each data set and 
overlay program specified. Space is reserved in these control blocks 
for the physical disk/diskette addresses of the data sets and overlay 
programs defined. 

After completion of the program preparation process ($LINK if 
required, and then $UPDATE), the executable load module may be 
loaded to storage. The system program that performs the load 
operation is $LOADER, and part of that operation includes filling in 
the actual physical addresses of data sets and overlay programs in the 
control blocks of the program header. When a large number of data 
sets and/or overlay programs are defined, this can be a time-consuming 
process, as $LOADER must search a volume directory for each data 
set/program used. 

To illustrate, the example program in Figure 14-55 has been assembled 
and formatted ($UPDATE), and stored on disk under the name MAIN. 

00001 PFNDEXMP PROGRAM START, DS=(DMY1 ,DMY2,DMY3,DMY4,DMY5) ,P6MS=(0VLY1 , C 

00002 0VLY2,0VLY3,0VLY4,0VLY5) 

00003 START PROGSTOP 

00004 ENDPROG 

00005 END 

Figure 14-55. Source for MAIN 

This program has five data sets and five overlay programs defined. Since 
any data sets or overlay programs used by a program must exist at the 
time the program is loaded, five 1-record data sets, DMY1 through 
DMY5 have been created using the AL function of $DISKUT1. 

Figure 14-56 is the source used to create the overlay programs. 

00010 OVLYPROG PROGRAM START 
00020 START PROGSTOP 
00030 ENDPROG 

00040 END 

Figure 14-56. Overlay source 
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The object module produced by assembly of this source has been 
successively processed by $UPDATE five times, each time providing a 
different load module name, 0VLY1 through 0VLY5. 

Figure 14-57 is a load request for program MAIN. 



LOAD REQUEST ENTERED 
^ AT 01:00:20 

> |$L MAINl 

MAIN 4P, 01:00:43, LP= 7800 



y 



MAIN ENDED AT 01:00:43 

Figure 14-57. Load request 

The amount of time elapsed, from the time the ENTER key is pressed 
to enter the $L MAIN command to the time the load message is 
returned, is 23 seconds by stopwatch. The majority of this time was 
taken in looking up the data set and overlay program locations for the 
control blocks in the program header. 

$PREFIND allows data set and overlay programs to be located prior 
to program load time, and written directly into the program header on 
disk/diskette. When the program is loaded, the information required 
is already present, and load time is therefore reduced. In Figure 14-58 
the example program MAIN is processed by $PREFIND. 



$L $prefind1 



> 

$PREFIND 26P, 00:57:40, LP= 7800 

COMMAND (?): |3 

PF PRELOCATE DATA SETS AND OVERLAYS 
DE DELETE PRE-FOUND STATUS 
EN END THE PROGRAM 

COMMAND (?): [pE . , 

PGM(NAME, VOLUME): IMAIN 



ENTER DATA SET NUMBERS: |D=(1 ,2,3,4,5) 
ENTER OVERLAY PGM. NUMBERS: iP=(ALL)| 



COMMAND COMPLETED 



COMMAND (?): [END 



Figure 14-58. $PREFIND operation 

In Figure 14-58, the "D=" entry could have been "ALL", just as it is 
for the "P=" entry, with the same effect. If you don't want all data 
sets or programs prelocated, you can selectively pre-find only those 
you wish, by entering the desired positional reference numbers and 
leaving out those you want the loader to find at load time. 

After the operation shown in Figure 14-58, load time for program 
MAIN is under three seconds. 
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Once a program has been processed by $PREFIND and "pre-found" 
status is established, the system makes no further checks to verify 
the validity of the data set/overlay program addresses in the program 
header. The AL and DE functions of $DISKUT1, or operations 
involving use of $C0PYUT1, $UPDATE, and $COMPRES can alter 
program/data set locations, and therefore invalidate a program's pre- 
found addresses. This could result in reading the wrong data, writing 
over important data, etc. $PREFIND is therefore not appropriate 
for use in test/development environments, and even in "stable" 
application environments should only be used with care. 



PROGRAM PREPARATION UTILITIES 
$EDIT1N 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$EDIT1 
and $EDIT1N Utility Programs." 

The $EDIT1 N text editing utility is used to create and edit source 
programs and other text data records such as the procedure files used 
with $JOBUTIL, or the control record files for $LINK. $EDIT1N 
(and also $EDIT1 and $FSEDIT) uses a data member as an edit work 
area. This work file must be preallocated by the user ($DISKUT1), 
and must be of sufficient size to contain the largest source program 
anticipated. The required size can be calculated as follows: number 
of text lines (n) divided by 30 times 11 plus 1 (n/30 x 11 + 1). The 
four primary text editor commands are: 

1 . READ — get the contents of a data set on a specified logical 
volume and store it in the work area data set, 

2. LIST — list the contents of the work area on the system printer 
(for the starter system on the matrix printer). 

3. END — terminate the text editor. 

4. EDIT — go into edit mode allowing the user to use any of the 
edit subcommands. 
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Figure 14-59 Is an example of a text edit session, demonstrating several 
of the EDIT mode subcommands, $EDIT1N is also used to edit the 
system configuration statements and link editor INCLUDE statements 
during system generation. See the topic "USER SYSTEM 
GENERATION" In "Section 15. System Installation." 



EXAMPLE: > $L$EDIT1N 



DS1(NAME, VOLUME): lEDITWORK 
$EDIT1N 47P, 00:08:01, LP= 5100 

READY 

[editH-Q 



EDIT 

IDE 10 250H «-H 
TOP OF DATASET 
|INPUTh -H 
INPUT 
00010 
00020 
00030 
00040 
00050 
00060 
00070 
00080 
00090 
00100 
00110 
00120 
00130 
00140 



%PRINT%NOGEN 

PGM1%PR0GRAM4%START,100 

START%PRINTEXT%TXT1,SKIP=2 

%ATTACH%TASK1 

%WAIT%E1, RESET 

°^PROGSTOP 

TXT1%TEXT%' PROGRAM STARTED' 

TXT"%TEXT%'TASK1 RUNNING' 

TASKmASK%GO,EVENT=El 

TASK1%TASK%G0,EVENT=E1 

G0%PRINTEXT%TXT2 

%ENDPROG 

%END 



EDIT 




CHANGE 


80 /T"/T2/-*-Q 


DELETE 




iUU ^ - KJ 


INPUT 







ID 



%ENDTASK 



INPUT 
00115 
INPUT TERMINATED 

Figure 14-59. $EDIT1N (1 of 2) 
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EDIT 

00010 

00020 PGMl 
00030 START 
00040 
00050 . 
00060 

00070 TXTl 
00080 TXT2 
00090 TASKl 
00110 GO 
00115 
00120 
00130 

END O F DATA 
fSAVTM B 
ENTER VOLUME 
ENTER MEMBER 
END AFTER 



PRINT 

PR0GRAM4 

PRINTEXT 

ATTACH 

WAIT 

PROGSTOP 

TEXT 

TEXT 

TASK 

PRINTEXT 

ENDTASK 

ENDPROG 

END 



NOGEN 
START, 100 
TXT1,SKIP=2 
TASKl 
El, RESET 

'PROGRAM STARTED 
'TASKl RUNNING' 
G0,EVENT=E1 
TXT2 



LABEL: EDXOOl 



NAME: [COPY 
13 



IODA,CTS= 002,047013,049010 
READY-*— E 

"endMH 



$EDIT1N ENDED AT 00:23:11 

Figure 14-59. $EDIT1N (2 of 2) 



COMMENTS: 



The Text Editor is loaded. 

A preal located data set to be used as a work area is specified. 

If you were updating a source module you would issue a READ 
indicating the data set name and volume that contain the file. In 
this example a new source module is being created, so EDIT 
mode is invoked without a preceding READ. 

This DELETE removes text lines remaining from a previous editing 
session (clears the work area) and positions the editor at the 
beginning (TOP) of the work area. 

To enter source statements you must issue the INPUT subcommand. 

The source statements entered are shown. The % in the text is used 
as the default TAB character. 

To end the INPUT subcommand depress the ENTER key or 
carriage return without entering any data. 

An error was made in the original entry on line 80. The slash is 
the delimiter between the change fields. Any non-numeric 
(except blank, TAB character or *) can be used as the delimiter. 
Here T2 replaces "T" in line 80. 
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El Another error was made in the original input. Line 90 and 100 are 
the same. Line 100 is deleted. 

[Q The user forgot to end the task with an ENDTASK instruction. 
It is now entered as line 115. 

DDJ Using the EDIT subcommand LIST, the contents of the work area 
are listed on the terminal. A LIST subcommand issued when not 
in EDIT mode will list the work area on the system printer. 

EB The data in the work area is now saved in a preal located user data 
set. The SAVE operation translates the source statements from 
the text editor format, in which they exist in the work area, into 
the normal source statement format which can be accepted by 
the assembler. The save is not destructive; the data is retained in 
the work area. 

EEI When the SAVE is complete, EDIT mode terminates. 

EQ To terminate the text editor, key in END. 



$UPDATE 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$UPDATE 
and $UPDATEN Utility Programs." 

$UPDATE is the utility used to format object modules into relocatable 
load modules, which can be loaded to storage and executed. 

COMMAND: RP 

FUNCTION: Read a program and convert it to a relocatable load 
module. 



EXAMPLE: > $L $UPDATE 



$UPDATE 



33P, 00:00:20, LP= 5100 



THE DEFINED INPUT VOLUME IS EDX002, OK? 
THE DEFINED OUTPUT VOLUME IS EDX002, OK? 

COMMAND (?): [RP] 



OBJECT MODULE NAME: DEMO 



OUTPUT PGM NAME: [FMT 
FMT REPLACE?|T| 
FMT STORED 



Figure 14-60. $UPDATE 
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COMMENTS: This example shows the formatting of an object module, 
DEMO. The executable output program, FMT, is stored. If a program 
member with the same name exists, you will be asked if it is to be 
replaced. If it does not exist, the utility will allocate the space for the 
executable program. The program, FMT, in the example can now be 
loaded by the $L operator command or by a LOAD instruction in a 
program. 



V. 



$FSEDIT 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes {SC34-1703), "$FSEDIT 
Utility Program." 

This utility provides full-screen text editing capability for the Event 
Driven Executive. $FSEDIT operates the terminal as a static screen 
device, and therefore must be run from a terminal with static-screen 
capability (4978/4979/3101 M2). 



Data Set Requirements. $FSEDIT requires a preallocated work data 
set for use as a text edit work area. Text data (source statements) 
within this work data set are in a special text editor format, identical 
to that used by the $EDIT1 N text editor; data within a text edit work 
data set may be edited by either $EDIT1N or $FSEDIT. 

At the conclusion of a text edit utility session, it is important to save 
the contents of the edit work data set in a source data set on disk or 
diskette (automatic translation from text editor format to source 
statement format is performed). 

$FSEDIT is loaded using $L operator command (the operator must 
provide the name of a text edit data set when the load request is 
entered). The operator will be prompted for the names of input/output 
source data sets during the utility session, at the time a READ or 
WRITE option is selected 



$FSEDIT Primary Options 



When $FSEDIT Is first loaded, the screen shown in Figure 14-61 will be 
displayed, with the cursor positioned just to the right of the SELECT 
OPTION arrow. An option is selected by entering a number corres- 
ponding to the desired option, and pressing the ENTER key. 
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Figure 14-61. $FSEDIT (1) 

Option 5: SUBMIT is used to submit a job to a host program prepara- 
tion system, and will therefore not be discussed in this section. The 
rest of the options will be illustrated in the order in which they would 
normally be required, not in the numerical sequence in which they 
appear in Figure 14-61. 



Creating A Source Statement File 



When the Primary Option Menu is displayed (Figure 14-61), entering a 
2 places the utility in EDIT mode. EDIT mode is used to modify an 
existing source data set, or to create a new one. When modifying an 
existing data set, a READ (option 3) of the file to be modified, into 
the edit work data set, must first be performed. This will be illustrated 
later. At this point, assume a new source statement file will be created. 

Invoking EDIT mode with an empty edit work data set will result in 
display of the screen in Figure 14-62. Because the work data set is 
empty, the editor assumes insertion (creation) of lines is desired, and 
the INSERT function is therefore active. The five dots to the left of 
the cursor will contain the statement number of the new line once it 
has been entered. The cursor is positioned at character position 1 of 
the insert line. 
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v_ 



Figure 14-62. $FSEDIT (2) 



The top line of the screen, from left to right, displays the mode the 
utility is in (EDIT), the name and volume of the work data set 
{EDITWORK,EDX002), the number of source statements in the work 
data set, and in parentheses, the total number of statements the data 
set will hold. 

In Figure 14-63, a line of asterisks and spaces has been entered on the 
insert line, and the ENTER key pressed. The utility numbers the 
entered line and sets up for the next insert line. 




Figure 14-63. $FSEDIT (3) 
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Notice that the "number of source statements in wori< data set' 
on the top line has incremented. 



value 



Continuing in this manner, with a new insert line readied each time the 
preceding line has been entered (ENTER key), the 18 comment state- 
ments (asterisk in position 1) shown in Figure 14-64 are created. The 
insert operation is terminated by pressing the ENTER key without 
entering anything on the new insert line. 




Figure 14-64. $FSEDIT (4) 



Option 4: WRITE 



The cursor is automatically positioned to the right of the COMMAND 
INPUT arrow oh the second line from the top of the screen. To return 
to the Primary Option Menu, the command "MENU" is entered, and the 
ENTER key pressed. This brings back the screen shown in Figure 14-61. 



The source statements just created will now be saved as a source data 
set. The WRITE primary option is selected, and the operator is 
prompted for the target data set/volume on the bottom half of the 
screen, as shown in Figure 14-65. 
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Options: READ 



Figure 14-65. $FSEDIT (5) 

After the contents of the work data set have been written, the prompt 
will be replaced by an ending message indicating how many statements 
had been written; in this example END AFTER 18. The cursor is re- 
turned to the SELECT OPTION input area. 



To edit an existing source file, it must first be transferred to the edit 
work data set. A diskette volume called ASM VOL is mounted, which 
contains a data set named SOURCE. By entering 3 and responding 
to the resulting prompts as shown in Figure 14-66, this file is read into 
the edit work data set. 
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Figure 14^6. $FSEDIT (6) 



Option 6: LIST 



Entering primary option 6 will list the contents of the work data set on 
the system printer. The data set SOURCE on ASMVOL contains the 
source file for the program used as an example in "Section 11. Terminal 
I/O". Listing the contents of the edit work area will produce the same 
listing as that shown in Figure 1 1-43, but with statement numbers 
printed to the left of each statement. 



Option 1: BROWSE 



The BROWSE option is used to examine a source file in the edit work 
data set, while precluding the possibility of changing it. Paging response 
will generally be faster in this mode. If option 1 is entered with the 
work data set containing the file from data set SOURCE, the screen in 
Figure 14-67 will be displayed. Note again the top line of the screen, 
indicating the operating mode (BROWSE) and the size of the file 
being examined (75 statements). 
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Figure 14-67. $FSEDIT (7) 

This file, as with most source files, is too large to be displayed in its 
entirety on the screen. In Figure 14-67, only the first 21 of the 75 
statements which make up the file are in view. 

To allow viewing of all parts of a file, both BROWSE (option 1 ) and 
EDIT (option 2) modes have a "scrolling" function, invoked by pressing 
PF keys. PF3 is used to scroll down in the data set, from top to 
bottom, and PF2 to scroll up, from bottom to top. 

In Figure 14-67, the scroll size is displayed at the extreme right of the 
second line. In BROWSE mode, the normal scroll size is PAGE; 22 
lines of data. In Figure 14-68, PF3 has been pressed, displaying the 
next 22 lines in the work area (statements 220 through 430). 
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BROUSE - EDITWORK, EDX002 


75( 270) COLUtlNS 001 072 


COMMAND INPUT = 


==> 


SCROLL ===>PAGE 


00220 


PRINTEXT 


DASHES. PR0TECT=YES,LINE=3 


00230 


PRINTEXT 


'CLASS NAME:',LINE=4,PR0TECT=YES 


00240 


PRINTEXT 


' INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 


00250 HDR 


PRINTEXT 


DASHES, PR0TECT=YES,LINE=5 


00260 


MOVE 


LINENBR.e 


00270 


DO 


4, TIMES 


00280 


PRINTEXT 


'NAME: • ,LINE=LINENBR,PROTECT=YES 


00290 


PRINTEXT 


'STREET:, LINE=LINENBR,SPACES= 30, PROTECT=YES 


00300 Al 


ADD 


LINENBR.l 


00310 


PRINTEXT 


'CITY : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 


00320 A2 


ADD 


LINENBR,! 


00330 


PRINTEXT 


'STATE : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 


00340 


ADD 


LINENBR, 3 


00350 


ENDDO 




00360 


PRINTEXT 


LINE=4,SPACES=11 


00370 


TERMCTRL 


DISPLAY 


00380 WAITONE 


WAIT 


KEY 


00390 


GOTO 


(READ,El,E2.E3,E4),XMPLSTAT+2 


00400 El 


HOVE 


LINENBR, 6 


00410 


GOTO 


DELETE 


00420 E2 


HOVE 


LINENBR, 11 


00430 


GOTO 


DELETE 



Figure 14-68. $FSEDIT (8) 

The scroll size may be defined as HALF by moving the cursor to the 
scroll size area and entering HALF where PAGE now is. HALF indicates 
half a page, or 1 1 lines. In Figure 14-69, scroll size has been defined as 
HALF, and PF3 has been pressed, displaying 1 1 new lines of data. 



BROWSE 


- EDITWORK. EDX002 


75( 270) - 


— COLUMNS 001 072 


COMMAND 


INPUT = 


==> 




SCROLL ===;|hAlI-| 


00330 




PRINTEXT 


'STATE : ' ,LINE=LINENBR,SPACES=30, 


PROTECT=YES 


00340 




ADD 


LINENBR, 3 




00350 




ENDDO 






00360 




PRINTEXT 


LINE=4,SPACES=11 




00370 




TERMCTRL 


DISPLAY 




00380 WAITONE 


WAIT 


KEY 




00390 




GOTO 


(READ,El,E2,E3,E4),XMPLSTAT+2 




00400 


El 


MOVE 


LINENBR, 6 




00410 




GOTO 


DELETE 




00420 


E2 


MOVE 


LINENBR, 11 




00430 




GOTO 


DELETE 




00440 


E3 


MOVE 


LINENBR, 16 




00450 




GOTO 


DELETE 




00460 


E4 


MOVE 


LINENBR, 21 




00470 


DELETE 


ERASE 


MODE=LINE,TYPE=DATA,LINE=LINEBR 




00480 




ADD 


LINENBR, 1 




00490 




ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




00500 




ADD 


LINENBR, 1 




00510 




ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 




00520 




SUBTRACT 


LINENBR, 2 




00530 




PRINTEXT 


LINE=LINEBR,SPACES=5 




00540 




TERMCTRL 


DISPLAY 





Figure 14-69. $FSEDIT (9) 



The third and last scroll size option is MAX. With MAX, the scroll will 
be all the way to the top (PF2) or bottom {PF3) of the data set. After 
the MAX scroll operation, scroll size reverts to the normal scroll size 
for the mode in effect (normal scroll size for BROWSE mode is 
PAGE, and for EDIT mode is HALF). 
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While in BROWSE mode, the primary command LOCATE can be 
used to position the displayed data beginning at a specific statement 
number. In Figure 14-70, the primary command LOCATE 450 is 
entered into the command input area on the second line. 



BROWSE - 
COMMAND 
***** 
00010 
00020 
00030 
00040 
00050 
,00060 
00070 
00080 
00090 
00100 
00110 
00120 
00121 
00140 
00150 
00160 
00170 
00180 
00190 
00200 
00210 



EDITWORK, E0X002 
INPUT === 



75( 270)- 



COLUMNS 001 07? 
SCROLL =-> PAGE 



LOCATE 450n 

***** YOP OF DATA ****************************************************** 
XMPLSTAT PROGRAM START 
lOCBl IOCS NHIST=0 
I0CB2 lOCB SCREEN=STATIC 

(END.OUT.SPF .STATIC) 
START ENQT lOCBl 

'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

'THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

'BRING UP THE ENTRY SCREEN' 



CHECK 



ENTRY 



lOCB 

lOCB 

ATTNLIST 

ENQT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

DEQT 

WAIT 

IF 

ENQT 

ERASE 

TERMCTRL 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 



ATTNECB, RESET 

(ATTNECB.EQ.D.GOTO.EMDIT 

I0CB2 

MODE=SCREEN,TYPE=ALL 

BLANK 

'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PFl = DELETE ENTRY 1' 

PF2 = DELETE ENTRY 2' 
'PF3 = DELETE ENTRY 3 ' ,SKIP= 
'PF4 = DELETE ENTRY 4' 



Figure 14-70. $FSEDIT (10) 



When the enter key is pressed, the screen in Figure 14-71 will be dis- 
played starting with statement 450. 



BROWSE - EDITWORK. EDX002 


75( 270) COLUMNS 001 072 


mm' '''''' '- 


GOTO 


SCROLL ===>PAGE 
DELETE 


00460 E4 


MOVE 


LINENBR,21 


00470 DELETE 


ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 


00480 


ADD 


LINENBR.l 


00490 


ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 


00500 


ADD 


LINENBR.l 


00510 


ERASE 


MODE=LINE,TYPE=DATA,LINE=LINENBR 


00520 


SUBTRACT 


LINENBR,2 


00530 


PRINTEXT 


LINE=LINENBR,SPACES=5 


00540 


TERMCTRL 


DISPLAY 


00550 


GOTO 


WAITONE 


00560 READ 


QUESTION 


'MORE ENTRIES ?' .LINE=2,SPACES=55,N0=CLEANUP 


00570 


ERASE 


M0DE=LINE.LINE=2.SPACES=55.TYPE=DATA 


00580 


ERASE 


M0DE=SCREEN,LINE=6 


00590 


PRINTEXT 


LINE=6,SPACES=5 


00600 


TERMCTRL 


DISPLAY 


00610 


GOTO 


WAITONE 


00620 CLEANUP 


ERASE 


MODE=SCREEN.TYPE=ALL 


00630 


DEQT 




00640 


GOTO START 


00650 ENDIT 


PROGSTOP 




00660 


DATA 


X'5050' 



Figure 14-71. $FSEDiT (11) 
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The "FIND" primary command performs the same type of positioning 
function using a text string instead of a statement number. In Figure 
14-72 the command, FIND/ENDIT P/FIRST, is entered in the 
command input area. 

The FIRST option means look for the text string beginning with the 
first statement in the data set. If Fl RST is not specified, the search will 
begin with the first statement of the currently displayed screen. In this 
example, because the current screen is also the top of the data set, both 
options have the same effect. 




Figure 14-72. $FSEDIT (12) 

When the ENTER key is pressed, the screen in Figure 14-73 will be 
displayed. The first statement is the statement containing the text 
string defined in the FIND command. The cursor will be positioned 
under the first character of the target string. 
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Option?: MERGE 



BROWSE - EDITUORK, EDX002 


75{ 2 


COriMAND INPUT == 


r=> 




00550 ENDIT 


PROGSTOP 




00660 


DATA 


X'5050' 


00670 DASHES 


DATA 


80C'-' 


00680 OUT 


POST 


ATTNECB, 1 


00690 


ENDATTN 




00700 STATIC 


POST 


ATTNECB, - 


00710 


ENDATTN 




00720 ATTNECB 


ECB 




00730 LINENBR 


DATA 


F'O' 


00740 


ENDPROG 




00750 


END 





270). 



- CHARACTERS FOUND 
SCROLL ===>PAGE 



***** ***** BOTTOM OF DATA **************************************************** 



Figure 14-73. $FSEDIT (13) 

If you want to find more than one occurrence of the same text string, 
the FIND command does not have to be reentered for each search. The 
first occurrence of the text string will be displayed as already illus- 
trated. If PF4 is pressed, the search will continue. Each time the string 
is found, the statement containing the string will be displayed at the 
top of a new screen. Each time PF4 is pressed the search will continue, 
until the end of the data set is reached. 

LOCATE, FIND, and MENU are the only primary commands recognized 
by BROWSE mode. MENU brings up the Primary Option Menu, shown 
in Figure 14-61. 



Option 7 allows you to combine (merge) two or more source data sets 
in the same edit work area? To demonstrate this option, a portion of 
the set of source statements created earlier (Figure 14-66) and stored 
in data set MRGDATA (Figure 14-65) will be merged with the current 
contents of the work area. 

When option 7 is entered, you will be prompted on the lower half of 
the screen as shown in Figure 14-74. With the responses shown, state- 
ments 100 through 180 of data set MRGDATA will be merged into the 
present contents of the work data set following statement 30. 
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Figure 14-74. $FSEDIT (14) 



Option 2: EDIT 



When option 2 is entered, the screen in Figure 14-75 is displayed. 
Notice that the merged statements have been inserted, and the entire 
data set renumbered. 




Figure 14-75. $FSEDIT (15) 
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In addition to LOCATE, FIND, and MENU, EDIT mode recognizes the 
CHANGE, RENUM, and RESET primary commands. In Figure 14-75, 
the primary command "CHANGE /END/QUIT/FIRST" is entered in 
the command input field. This command will look for the first occur- 
rence of the text string END, starting with the first statement in the data 
set (Fl RST). If NEXT is entered, the search would begin with the first 
statement on the current screen (the two statements have the same 
results in this example). When the text string END is found, it will be 
replaced with the text string QUIT. The first occurrence of END is in 
the ATTNLIST statement, at statement number 130 (Figure 14-75). 
In Figure 16-17, the ENTER key has been pressed, END has been 
changed to QUIT, and the first line displayed is the line the change 
occurred in. By pressing PF5, the CHANGE command can be repeated, 
with the search beginning with statement 130. 



EDIT — EDITW0RK,EDX002 
COMMAND INPUT -==> 
00130 



00140 START 

00150 

00160 

00170 

00180 

00190 

00200 

00210 CHECK 

00220 

00230 ENTRY 

00240 

00250 

00260 

00270 

00280 

00290 

00300 

00310 

00320 

00330 

00340 HDR 



ATTNLIST 

ENQT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

DEQT 

WAIT 

IF 

ENQT 

ERASE 

TERMCTRL 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 



84{ 270)— - TEXT CHANGED 

SCROLL ===><ALF 
(QUIT,OUT,$PF, STATIC) 
lOCBl 

'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 
'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 
' THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 
' BRING UP THE ENTRY SCREEN" 

ATTNECB, RESET 

(ATTNECB.EQ.D.GOTO.ENDIT 

I0CB2 

MODE=SCREEN,TYPE=ALL 

BLANK 

'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PFl = DELETE ENTRY 1' 

PF2 = DELETE ENTRY 2' 
'PF3 = DELETE ENTRY 3 ' ,SKIP=1 
'PF4 = DELETE ENTRY 4' 
DASHES, PR0TECT=YES,LINE=3 
'CLASS NAME: ',LINE=4,PR0TECT=YES 
'INSTRUCTOR NAME: 'LINE=4,PR0TECT=YES,SPACES=32 
DASHES ,PROTECT=YES ,LINE=5 



Figure 14-76. $FSEDIT (16) 

If you want to change every occurrence of a text string in the entire 
work area, ALL should be entered in place of FIRST or NEXT. 

When in EDIT mode, changes to the displayed data may be entered 
directly onto the screen. In Figure 14-77, the QUIT in statement 
130 has been changed back to END by overtyping. 
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EDIT — 


EDITWORK, EDX002 


COMMAND : 


INPUT == 


==> 


00130 




ATTNLIST 


00140 START 


ENQT 


00150 




PRINTEXT 


00160 




PRINTEXT 


00170 




PRINTEXT 


00180 




PRINTEXT 


00190 




PRINTEXT 


00200 




DEQT 


00210 


CHECK 


WAIT 


00220 




IF 


00230 


ENTRY 


ENQT 


00240 




ERASE 


00250 




TERHCTRL 


00260 




PRINTEXT 


00270 




PRINTEXT 


00280 




PRINTEXT 


00290 




PRINTEXT 


00300 




PRINTEXT 


00310 




PRINTEXT 


00320 




PRINTEXT 


00330 




PRINTEXT 


L 00340 


HDR 


PRINTEXT 



TEXT CHAfMJtD 

SCROLL ===> "^ 



84 ( 270) — 

(END, OUT, $PF, STATIC) 

lOCBl 

'CLASS ROSTER PROGRAM', SPACES=15,LINE=1 

'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

' THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

' BRING UP THE ENTRY SCREEN' 

ATTNECB, RESET 

(ATTNECB,EQ,1),G0T0,ENDIT 

I0CB2 

MODE=SCREEN,TYPE=ALL 

BLANK 

'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PFl = DELETE ENTRY 1' 

PF2 = DELETE ENTRY 2' 
'PF3 = DELETE ENTRY 3 ',SKIP=1 

'PF4 = DELETE ENTRY 4' 
DASHES ,PROTECT=YES ,LINE=3 
'CLASS NAME: ' ,LINE=4,PR0TECT=YES 
'INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 
DASHES, PR0TECT=YES,LINE=5 



Figure 14-77. $FSEDIT (17) 



The Statements in the work data set may be renumbered using the 
RENUM primary command. In Figure 14-78, the RENUiVI command 
is used to renumber the data set in increments of 5, with the first 
statement assigned a statement number of 1 . 




Figure 14-78. $FSEDIT (18) 



Figure 14-79 is the resulting display, after the ENTER key has been 
pressed. 
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V 



Figure 14-79. $FSEDIT (19) 



The RESET primary command is used in conjunction with the EDIT 
mode line commands, and will be illustrated later. 



Edit Mode Line Commands 



In addition to modification of text strings using the CHANGE primary 
command, and the modification of any displayed data on the screen 
by overtyping, EDIT mode also allows whole lines, or blocks of lines to 
be manipulated, using the EDIT mode line commands. For example, 
the INSERT (I) command allows a new line to be inserted between 
existing lines. In Figure 14-80, an "I" is entered to the left of statement 
40, indicating that the operator wishes to insert between statement 40 
and 50. 
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EDIT - 


-- EDITWORK. EDX002 84( 270) COLUMNS 001 072 


COHHAND INPUT ===> 


SCROLL -=-> 

HALF 


***** 


***** TOP OF DATA 


****************************************************** 


00010 


XMPLSTAT PROGRAM 


START 


00020 


lOCBl lOCB 


NHIST=0 


^ 00030 


I0CB2 lOCB 


SCREEN=STATIC 


Tj 00040 


********* 


**************************** 


00050 


* 




00060 


* MERGE DATA 




00070 


* MERGE DATA 




00080 


* MERGE DATA 




00090 


* MERGE DATA 




00100 


* MERGE DATA 




00110 


* 




00120 


********* 


*************************** 


00130 


ATTNLIST 


(END, OUT. $PF, STATIC) 


00140 


START ENQT 


lOCBl 


00150 


PRINTEXT 


'CLASS ROSTER PROGRAM' ,SPACES=15.LINE=1 


00160 


PRINTEXT 


'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 


00170 


PRINTEXT 


' THE PROGRAM' 


00180 


PRINTEXT 


'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 


00190 


PRINTEXT 


' BRING UP THE ENTRY SCREEN' 


00200 


DEQT 




L. 00210 


CHECK UAIT 


ATTNECB, RESET 



Figure 14-80. $FSEDIT (20) 

When ENTER is pressed, the screen comes back as pictured in Figure 
14-81 , with the insert line displayed, and the cursor in the first charac- 
ter position, ready for entry. 



EDIT — EDITUORK. EDX002 84( 270)-- COLUMNS 001 072 

COMMAND INPUT ===> SCROLL ■-■=--^i^ 

***** ***** jop OF DATA ****************************************************** 

00010 XMPLSTAT PROGRAM START 

00020 lOCBl lOCB NHIST=0 

00030 I0CB2 lOCB SCREEN=STATIC 

00040 ************************************ 



00050 


■* 






00060 


* 


MERGE 


DATA 


00070 


* 


MERGE 


DATA 


00080 


* 


MERGE 


DATA 


00090 


* 


MERGE 


DATA 


00100 


* 


MERGE 


DATA 


00110 


* 






00120 


* 


* * * 


* * * * * 


00130 






AHNLIST 


00140 


START 


ENQT 


00150 






PRINTEXT 


00160 






PRINTEXT 


00170 






PRINTEXT 


00180 






PRINTEXT 


00190 






PRINTEXT 


00200 






DEQT 



*********************** 
(END, OUT. $PF, STATIC) 
lOCBl 

'CLASS ROSTER PROGRAM' ,SPACES=15.LINE=1 
'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 
' THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 
' BRING UP THE ENTRY SCREEN' 



Figure 14-81. SFSEDIT (21) 

When the insert line is complete, the operator presses the ENTER key, 
the new line is assigned a statement number, and another insert line is 
readied (Figure 14-82). 
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EDIT — EDITWORK, EDX002 85( 270)- COLUMNS 001 072 

COMMAND INPUT -=> SCROLL =--==>HALF 

***** ***** joP OF DATA ****************************************************** 

00010 XMPLSTAT PROGRAM START 

00020 lOCBl lOCB NHIST=0 

00030 I0CB2 lOCB SCREEN=STATIC 

00040 ************************************ 

00041 * I INSERT SINGLE LINE I 



00050 


T 






00060 


* 


MERGE 


DATA 


00070 


* 


MERGE 


DATA 


00080 


* 


MERGE 


DATA 


00090 


* 


MERGE 


DATA 


00100 


* 


MERGE 


DATA 


00110 


* 






00120 


* 


* * * 


* * * * * 


00130 






ATTN LI ST 


00140 


START 


ENQT 


00150 






PRINTEXT 


00160 






PRINTEXT 


00170 






PRINTEXT 


00180 






PRINTEXT 


00190 






PRINTEXT 



*************************** 
(END, OUT, $PF, STATIC) 
lOCBl 

'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 
■HIT "ATTN" AND ENTER "END" TO END',SKIP=2 
" THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY TO' ,SKIP=2 
' BRING UP THE ENTRY SCREEN' 



Figure 14-82. $FSEDIT (22) 



The operation terminates when ENTER is pressed with no characters 
entered on the insert line. 

The INSERT BLOCK (II) command generates a block of 21 insert 
lines. In Figure 14-83 the "M" to the left of statement 50 indicates 
the operator wants to generate the insert block following statement 
50. 




Figure 14-83. $FSEDIT (23) 



When ENTER is pressed, the screen in Figure 14-84 is displayed. 
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Figure 14-84. $FSEDIT (24) 

The operator may now fill in the screen as required, without pressing 
ENTER for each line (Figure 14-85). 




Figure 14-85. $FSEDIT (25) 

When as much data as desired has been entered, the ENTER key is 
pressed. 

Unused insert lines are removed, the insert lines used are assigned 
statement numbers, and the screen appears as shown in Figure 14-86. 
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Figure 14-86. $FSEDIT (26) 



The MOVE (M) line command will move a line from one location in 
the work data set to another. In Figure 14-87, an "M" is entered to 
the left of the line to be moved, statement 50. The "A" at statement 
140 specifies the destination of the MOVE as after line 140. 




Figure 14-87. SFSEDIT (27) 



Figure 14-88 is the screen displayed after ENTER is pressed. The line 
is moved, and the data set renumbered. 
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Figure 14-88. $FSEDIT (28) 



The MOVE BLOCK line command (MM) is illustrated in Figure 14-89. 
The MM to the left of statements 60 and 80 define the inclusive start 
and end points of a block of statements to be moved. The B defines 
the destination of the block as before statement 150. (Either A or B 
can be used with M and MM.) 



EDIT — 
COMMAND 
00020 
00030 
00040 
00050 

(mm] 00060 
00070 

ImTI 00080 

— ^00090 
00100 
00110 
00120 
00130 
00140 

fn 00150 
00160 
00170 
00180 
00190 
00200 
00210 
00220 
00230 



COLUMNS 001 072 
SCROLL ==.--> HALF 



- F.DITW0RK,ED>;002 88( 270) 

INPUT ==-> 
lOCBl lOCB NHIST=0 

I0CB2 lOCB SCREEN=STATIC 
************************************* 

* 

* INSERT 

* MULTIPLE 

* LINES 

* MERGE DATA 

* MERGE DATA 

* MERGE DATA 

* MERGE DATA 

* MERGE DATA 

* INSERT SINGLE LINE 
* 
****************************** ***** 

ATTNLIST (END, OUT, $PF, STATIC) 

START ENQT lOCBl 

PRINTEXT 'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

PRINTEXT 'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

PRINTEXT ' THE PROGRAM' 

PRINTEXT 'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

PRINTEXT 'BRING UP THE. ENTRY SCREEN' 



Figure 14-89. $FSEDIT (29) 



After ENTER is pressed, the screen in Figure 14-90 is displayed. 
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EDIT — 


EDITWORK, EDX002 


88{ 270) BLOCK — DATA RENUMBERED 


COMMAND INPUT =-= 


=> 


SCROLL --=> 








HALF 


00110 


* INSERT SINGLE LINE 


00120 


* INSERT 




00130 


* MULTIPLE 




00140 


* LINES 




00150 


* 






00160 


* * * * 


***** 


**************************! 


00170 




ATTNLIST 


(END, OUT, $PF. STATIC) 


00180 


START 


ENQT 


lOCBl 


00190 




PRINTEXT 


'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 


00200 




PRINTEXT 


•HIT "ATTN" AND ENTER "END" TO END',SKIP=2 


00210 




PRINTEXT 


' THE PROGRAM' 


00220 




PRINTEXT 


'HIT ANY PROGRAM FUNCTION KEY TO' ,SKIP=2 


00230 




PRINTEXT 


' BRING UP THE ENTRY SCREEN' 


00240 




DEQT 




00250 


CHECK 


WAIT 


ATTNECB, RESET 


00260 




IF 


(ATTNECB,EQ,1),G0T0,ENDIT 


00270 


ENTRY 


ENQT I0BC2 


00280 




ERASE 


MODE=SCREEN,TYPE=ALL 


00290 




TERMCTRL 


BLANK 


00300 




PRINTEXT 


'ENTER KEY = PAGE COMPLETE' ,LINE=1 


00310 




PRINTEXT 


PFl - DELETE ENTRY 1' 


I 00320 




PRINTEXT 


PF2 = DELETE ENTRY 2' 



Figure 14-90. $FSEDIT (30) 



The MOVE and MOVE BLOCK commands removed statements from 
one part of the work data set and placed them in another. The COPY 
(C) and COPY BLOCK (CC) line commands reproduce an exact copy 
of the designated statement(s) at another location in the data set with- 
out disturbing the original. In Figure 14-91 , statement number 1 10 is 
to be copied after statement 40. 



£DIT — - EDITWORK, EDX002 
COMMAND INPUT =■=-> 



88( 270) COLUMNS 001 072 

SCROLL ===> 

HALF 

***** ***** JQp Qp [)/\J/\ ****************************************************** 

00010 XMPLSTAT PROGRAM START 
00020 lOCBl lOCB NHIST=0 
00030 I0CB2 lOCB SCREEN=STATIC 
TAb0040 ************************************ 
00050 * 

00060 * MERGE DATA 
MERGE DATA 
MERGE DATA 
MERGE DATA 

_ MERGE DATA 

mOOllO * INSERT SINGLE LINE 

- INSERT 

MULTIPLE 
LINES 



00070 * 

00080 * 

00090 * 
_00100 * 

DOllO * 
■'00120 * 

00130 * 

00140 * 

00150 * 

00160 ************************************ 

00170 ATTNLIST (END,OUT,$PF, STATIC) 

00180 START ENQT lOCBl 

00190 PRINTEXT 'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

00200 PRINTEXT 'HIT "ATTN" AND ENTER "END" TO END",SKIP=2 

00210 PRINTEXT ' THE PROGRAM' 



Figure 14-91. $FSEDIT (31) 



In Figure 14-92, the operation is complete (ENTER key has been 
pressed). 
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Figure 14-92. $FSEDIT (32) 



In Figures 14-93 and 14-94, the same operation is performed with the 
COPY BLOCK (CC) line command, copying statements 130 through 
150. 




Figure 14-93. SFSEDIT (33) 
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Figure 14-94. SFSEDIT (34) 



When the INSERT LINE (I) and INSERT BLOCK (II) line commands 
were discussed (Figures 14-80 through 14-85), the I command resulted 
in the display of a blank insert line. This insert line is actually an insert 
mask, initialized to blanks. The insert mask may be displayed using the 
MASK line command. In Figure 14-95, the MASK command is typed 
in over the first four digits of the sequence number of statement 40. 
It does not matter what statement's sequence number is overtyped; 
the data on that line is not destroyed. 




Figure 14-95. SFSEDIT (35) 
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When the ENTER key is pressed, the insert masl< is displayed. As you 
can see in Figure 14-96, the insert mask is the line of blanks that was 
inserted every time you entered the I command. 



92( 270)- COLUMNS 001 072 

SCROLL — > HALF 



EDIT — EDITWORK, EDX002 
COMMAND INPUT ===> 

***** ***** JQp Qp D/\Y/\ ****************************************************** 

00010 XMPLSTAT PROGRAM START 

00020 lOCBl lOCB NHIST=0 

00030 I0CB2 lOCB SCREEN=STATIC 

00040 ************************************ 

MASK 



00050 * 


INSERT SINGLE LINE 


00060 * 


INSERT 


00070 * 


MULTIPLE 


00080 * 


LINES 


00090 * 




00100 * 


MERGE DATA 


00110 * 


MERGE DATA 


00120 * 


MERGE DATA 


00130 * 


MERGE DATA 


00140 * 


MERGE DATA 


00150 * 


INSERT SINGLE LINE 


00160 * 


INSERT 


00170 * 


MULTIPLE 


00180 * 


LINES 


00190 * 





00200 



************************************ 



Figure 14-96. $FSEDIT (36) 

(Notice that statement 40, whose sequence number was used for the 
MASK command input field. Is intact.) 

You can redefine the insert mask to be any character string you wish. 
In Figure 14-97, the mask has asterisks entered in the leading and 
ending character positions. 



EDIT — • EDITWORK, EDX002 92( 270) — COLUMNS 001 072 

COMMAND INPUT --===> SCROLL -=-> HALF 

***** ***** JQP QP Q/\jy\ ****************************************************** 

00010 XMPLSTAT PROGRAM START 
00020 lOCBl lOCB NHIST=0 

00030 I0CB2 lOCB SCREEN=STATIC 

00040 ************************************ 

[********** I 



MASK 1**********1 




00050 * 


INSERT SINGLE 


LINE 


00060 * 


INSERT 




00070 * 


MULTIPLE 




00080 * 


LINES 




00090 * 






00100 * 


MERGE DATA 




00110 * 


MERGE DATA 




00120 * 


MERGE DATA 




00130 * 


MERGE DATA 




00140 * 


MERGE DATA 




00150 * 


INSERT SINGLE 


LINE 


00160 * 


INSERT 




00170 * 


MULTIPLE 




00180 * 


LINES 





00190 * 

00200 ************************************ 



Figure 14-97. SFSEDIT (37) 
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To get out of this insert mask display/definition mode, move the cursor 
to the primary command input area on the second line of the screen, 
type in the primary command RESET, and press ENTER. 

The RESET primary command is also used to reset undesired but 
already entered line commands, and to reset error conditions resulting 
from improper use of line commands. 

Now that the insert mask display has been RESET, a Line Insert com- 
mand is entered (Figure 14-98). 



EDIT --■ 


- EDITWORK, EDX002 92{ 270) - COLUMNS 001 072 


COMMAND 


If^PUT =■•-•■> SCROLL — >HALF 


***** 


***** JQp Qp Q/\"r/\ ****************************************************** 


00010 


XMPLSTAT PROGRAM START 


00020 


lOCBl lOCB NHIST=0 


00030 


I0CB2 lOCB SCREEN=STATIC 


00040 


************************************ 


00050 


* INSERT SINGLE LINE 


00060 


* INSERT 


00070 


* MULTIPLE 


00080 


* LINES 


Ei 00090 


* 


00100 


* MERGE DATA 


00110 


* MERGE DATA 


00120 


* MERGE DATA 


00130 


* MERGE DATA 


00140 


* MERGE DATA 


00150 


* INSERT SINGLE LINE 


00160 


* INSERT 


00170 


* MULTIPLE 


00180 


* LINES 


00190 


* 


00200 


************************************ 


, 00210 


ATTNLIST (END, OUT, $PF, STATIC) 



Figure 14-98. $FSEDIT (38) 



When the insert line appears, the line contains the redefined mask 
characters (Figure 14-99). 
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92( 270)- 



COLUMNS 001 072 
SCROLL ^'^<>HALF 



****************************************************** 



EDIT — EDITWORK, EDX002 
COMMAND INPUT =■'==> 

***** ***** 70P OF DATA 

00010 XMPLSTAT PROGRAM START 

00020 lOCBl lOCB NHIST=0 

00030 I0CB2 IOCS SCREEN=STATIC 

00040 *********************************** 

00050 * INSERT SINGLE LINE 



********** 



00060 * 


INSERT 


00070 * 


MULTIPLE 


00080 * 


LINES 


00090 * 




********** 


00100 * 


MERGE DATA 


00120 * 


MERGE DATA 


00130 * 


MERGE DATA 


00140 * 


MERGE DATA 


00150 * 


INSERT SINGLE LINE 


00160 * 


INSERT 


00170 * 


MULTIPLE 


00180 * 


LINES 



00190 * 

00200 ************************************ 



Figure 14-99. $FSEDIT (39) 

Each time another insert line appears, the mask characters are displayed. 
You can enter data on top of them if desired, or in the blank areas 
between them, as in Figure 14-100. 




Figure 14-100. $FSEOIT (40) 

The DELETE Line (D) and DELETE Block (DD) line commands 
remove statement(s) from the work data set. In Figure 14-101, the 
D command is entered to the left of line 50. 
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EDIT — EDITWORK. EDX002 95{ 270) COLUMNS 001 072 

COMMAND INPUT ===> SCROLL •■■^==:;>hALF 

***** ***** joP OF DATA ****************************************************** 
00010 XMPLSTAT PROGRAM START 
00020 lOCBl lOCB NHIST=0 
00030 I0CB2 lOCB SCREEN=STATIC 

00040 ************************************ 
INSERT SINGLE LINE 
INSERT 
MULTIPLE 
LINES 




********** 
********** 
********** 

* MERGE DATA 

* MERGE DATA 

* MERGE DATA 

* MERGE DATA 

* MERGE DATA 

* INSERT SINGLE LINE 

* INSERT 

* MULTIPLE 

* LINES 



WITH THE INSERT MASK DEFINED, EACH TIME AN 
INSERT LINE IS DISPLAYED, THE MASK CHARACTERS 
ARE DISPLAYED ON THE SAME LINE. 



********** 
********** 
********** 



Figure 14-101. $FSEDIT (41) 



After the ENTER key is pressed, the screen in Figure 14-102 appears 
with line 50 deleted. 




Figure 14-102. $FSEDIT (42) 

In Figure 14-103, the first statement of a block delete is defined with 
the DD command. 
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Figure 14-103. $FSEDIT (43) 

The ending statement to be deleted is not displayed on this screen, so 
PF3 is pressed, scrolling down a half-page, to the screen displayed in 
Figure 14-104. 



EDIT -- [ 


DITWORK, EDX002 


94( 270) BLOCK COMMAND INCOMPLETE 


COMMAND INPUT ===> 


SCROLL -— > HALF 


00093 ********** ARE DISPLAYED ON THE SAME LINE. ********** 


00100 * 


MERGE DATA 




00110 * 


MERGE DATA 




00120 * 


MERGE DATA 




00130 * 


MERGE DATA 




00140 * 


MERGE DATA 




00150 * 


INSERT SINGLE LINE 


00160 * 


INSERT 




00170 * 


MULTIPLE 




00180 * 


LINES 




00190 * 






inaoo2oo * 


******** 


*************************** 


00210 


ATTNLIST 


(END, OUT, $PF, STATIC) 


00220 START ENQT 


lOCBl 


00230 


PRINTEXT 


■CLASS ROSTER PROGRAM" ,SPACES=15,LINE=1 


00240 


PRINTEXT 


'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 


00250 


PRINTEXT 


' THE PROGRAM' 


00260 


PRINTEXT 


'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 


00270 


PRINTEXT 


' BRING UP THE ENTRY SCREEN' 


00280 


DEQT 




00290 CHECK WAIT 


ATTNECB, RESET 


i 00300 


■ IF 


(ATTNECB,EQ,1),G0T0,ENDIT 



Figure 14-104. $FSEDIT (44) 



(The scope of the C, CC, M, MM, D, and DD line commands extends 
from the beginning to the end of the data in the work area, not just the 
data on the current screen.) 

The end of the Delete Block is entered at statement 200 (Figure 14-104), 
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After the command is entered, the screen in Figure 14-105 is displayed. 
All statements merged, inserted, copied or moved during the course of 
this exercise have been deleted, and the data set is in the same state it 
was in when It was first read from SOURCE. 



EDIT 
COMMAND 

00210 

00220 START 

00230 

00240 

00250 

00260 

00270 

00280 

00290 CHECK 

00300 

00310 ENTRY 

00320 

00330 

00340 

00350 

00360 

00370 

00380 

00390 

00400 

00410 

00420 HDR 



- EDITMORK, EDX002 
INPUT ==-> 

ATTN LI ST 

ENQT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

DEQT 

WAIT 

IF 

ENQT 

ERASE 

TERMCTRL 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 



75( 270) COLUMNS 001,07. 

(END,OUT,$PF, STATIC) 

lOCBl 

'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

' THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0'.SKIP=2 

' BRING UP THE ENTRY SCREEN' 

ATTNECB, RESET 

(ATTNECB,EQ,1),G0T0,ENDIT 

I0CB2 

MODE=SCREEN,TYPE=ALL 

BLANK 

'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PFl = DELETE ENTRY 1' 

PF2 = DELETE ENTRY 2' 
'PF3 = DELETE ENTRY 3 ' ,SKIP=1 
'PF4 = DELETE ENTRY 4' 
DASHES, PR0TECT=YES,LINE=3 
'CLASS NAME: ',LINE=4,PR0TECT=YES,SPACES=32 
'INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 
DASHES, PR0TECT=YES,LINE=5 



.^ 



Figure 14-105. $FSEDIT (45) 

The MENU primary command is entered in the command input field, 
and ENTER pressed. 



EDIT — 


EDiTwoRK. mmx? 


COMMAND 


INPUT == 


=> |MENU| 


00210 




ATTN LI ST 


00220 


START 


ENQT 


00230 




PRINTEXT 


00240 




PRINTEXT 


00250 




PRINTEXT 


00260 




PRINTEXT 


00270 




PRINTEXT 


00280 




DEQT 


00290 


CHECK 


WAIT 


00300 




IF 


00310 


ENTRY 


ENQT 


00320 




ERASE 


00330 




TERMCTRL 


00340 




PRINTEXT 


00350 




PRINTEXT 


00360 




PRINTEXT 


00370 




PRINTEXT 


00380 




PRINTEXT 


00390 




PRINTEXT 


00400 




PRINTEXT 


00410 




PRINTEXT 


00420 


HDR 


PRINTEXT 



75( 270)- 



COLUMNS 001 
SCROLL -==> 



(END, OUT, $PF. STATIC) 

lOCBl 

'CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

'HIT "ATTN" AND ENTER "END" TO END' ,SKIP=2 

' THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

' BRING UP THE ENTRY SCREEN' 

ATTNECB, RESET 

(ATTNECB, EQ,1), GOTO, ENDIT 

I0CB2 

MODE=SCREEN.TYPE=ALL 

BLANK 

'ENTER KEY = PAGE COMPLETE' ,LINE=1 

PFl = DELETE ENTRY 1' 

PF2 = DELETE ENTRY 2' 
'PF3 = DELETE ENTRY 3 ',SKIP=1 
'PF4 = DELETE ENTRY 4' 
DASHES, PR0TECT=YES,LINE=3 
'CLASS NAME:',LINE=4,PR0TECT=YES 
' INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 
DASHES , PR0TECT=YES , L I NE=5 



Figure 14-106. $FSEDIT (46) 



Option 8 
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The only Primary Option remaining to be discussed is option 8. 




Figure 14-107. $FSEDIT (47) 




Figure 14-108. $FSEDIT (48) 
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OTHER UTILITY PROGRAMS 



The following utility programs are used with system facilities not 
addressed as topics in this study guide. 



BSC Utilities 



$BSCTRCE 



$BSCUT1 



$BSCUT2 



READING REFERENCE: IBM Series/1 Event Driven Executive 
Communications and Terminal Applications Guide (SC34-1705), 
"$BSCTRCE Utility Program," "$BSCUT1 Utility Program," and 
"$BSCUT2 Utility Program." 



This utility traces I/O on a specified BSC line, and stores the trace data 
in a data set on disk or diskette. The data set must be preal located by 
the user, and the name supplied to the $BSCTRCE utility at the time 
the utility is loaded. Trace information Includes condition codes, status 
words, data transferred, and other indicators/information associated 
with BSC I/O operation. 



Trace information written by $BSCTRCE is retrieved and formatted 
into an easily understood report by $BSCUT1, and then directed to a 
specified terminal or print device. 



This utility is a BSC exerciser, used to test the BSC hardware adapter, 
and the match between the actual hardware configuration and what 
has been specified in the BSC LINE system configuration statement. 
Several BSC access method commands may be invoked to exercise 
various hardware/system software combinations. 
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DISPLAY PROCESSOR (GRAPHICS) UTILITIES 



READING REFERENCE: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "Graphics 
Utilities." 

The Display Processor facility allows the user to generate, store, and 
display information in graphic or report format. The information is 
contained in a data base created expressly for, and utilizing, data 
organization and data formatting conventions unique to the Display 
Processor. Display Processor support consists of three utility programs, 
which are used to create/maintain the data base, create or alter data 
members, or display a graphic or report data member. 



$DIUTIL 



$DICOMP 



$DIINTR 



This utility provides all data base maintenance functions for the Display 
Processor data base, including Initialization, member deletion/allocation, 
data base compression, and member/data base copy. 



A member within the Display Processor data base is called a display 
profile. This utility allows the operator to compose a display profile, or 
to alter (maintain) existing display profiles. 



A completed display profile (data base member) is made up of coded 
information representing an image or report. The $DIINTR utility 
retrieves a specified display profile, interprets the coded commands/ 
data it contains, and displays the resulting image. 

Note: Terminals used as graphics devices must have ASCII point-to- 
point vector graphics capability. 



HOST PROGRAM PREPARATION UTILITIES 



READING REFERENCE: IBM Series/1 Event Driven Executive 
Communications and Terminal Applications Guide (SC34-1705), 
"$HCFUT1 Utility Program." 
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$HCFUT1 



When program preparation is performed on a host System/370, the Host 
Communications Facility I UP (5796-PGH) must be installed on the 
host system. On the Series/1 side the $HCFUT1 utility program is used. 

$HCFUT1 is the basic Event Driven Executive utility program used to 
transfer data sets associated with program preparation between the 
Series/1 and a host system. The four functions available are; 

1 . READ a source/object data set from a host into a Series/1 data set 

2. WRITE a Series/1 source/object data set to a host data set 

3. SUBMIT a program preparation job to the host job stream 

4. SET/FETCH/RELEASE a record in the host System Status data 
set 



v.^' 



$EDIT1/$UPDATEH 



These are the host preparation equivalents of the native preparation 
text editing and object module formatting utilities $EDIT1N and 
$UPDATE. They differ from the native versions only in the commands 
used to store and retrieve source and object module data sets. For the 
native versions, any operation involving a data set transfer (READ/ 
SAVE/RP) requires that both the from and to data sets be resident on 
the Series/1. With the "host prep" versions, both will be resident on 
the host. 

$EDIT1 and $UPDATEH invoke the READ and WRITE (also SUBMIT 
for $EDIT1 ) functions of $HCFUT1 without the operator's having to 
load $HCFUT1 explicitly. If the operator does load $HCFUT1 and uses 
it for the necessary data set transfers, then the editing/formatting 
operations would be done with $EDIT1N and $UPDATE. 

Note: $FSEDIT, the full screen text edit utility, includes host prep data 
set transfer functions in its normal command menu; no separate 
version for host program preparation is required. 



—^ 



$RJE2780/$RJE3780 



READING REFERENCE: IBM Series/1 Event Driven Executive 
Communications and Terminal Application Guide {SC34-1705), 
"$RJE2780 and $RJE3780 Utility Programs" and "$PRT2780 and 
$PRT3780 Utility Programs." 



These utilities provide an alternative method of transferring data sets 
between a Series/1 and a host program preparation system. The 
$RJE2780 and $RJE3780 simulate the IBM 2780 and IBM 3780 
Remote Job Entry stations. Using the Series/1 BSC capability, 
$RJE2780 and $RJE3780 interface to System/360 or System/370 
systems with the Remote Job Entry facility installed (5796-PGH not 
required). 
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$PRT2780/$PRT3780 



$DEBUG 



These utilities print the RJE printer output spool files created when 
$RJE2780/$RJE3780 is used with the spooling option invoked. 



READING REFERENCE: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$DEBUG 
Utility Program." 

$DEBUG is the Event Driven Executive online debugging utility. 
$DEBUG may be used to debug any program instructions that execute 
as a task, including instructions written in Series/1 assembler language. 
$DEBUG capabilities include setting/resetting of breakpoints and trace 
ranges; display and modification of storage locations; Series/1 hardware 
registers, and task software registers; and alteration of task execution 
sequence. 
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Section 15. System Installation 



OBJECTIVES: 



After completing this section, the student should be able to generate a 
tailored supervisor for a given sample configuration, using the pro- 
grams/utilities provided in the Event Driven Executive Program Prepara- 
tion Facility. 



MACHINE READABLE MATERIAL 



The Event Driven Executive software offering for the Series/1 is com- 
prised of five separately orderable programs: 

1. 5719-XS3 Event Driven Executive Basic Supervisor and Emulator 

2. 5719-UT5 Event Driven Executive Utility Programs 

3. 5719-XX4 Event Driven Executive Program Preparation Facility 

4. 5719-LM7 Event Driven Executive Macro Library 

5. 5740-LM4 Event Driven Executive Macro Library/Host 



5719-XS3 Basic Supervisor and Emulator 

Diskette XS3001 contains the supplied starter supervisor and the neces- 
sary utilities to install the product. 

Diskette XS3002 contains supervisor object modules used during the 
system generation process. 

Diskette XS3003 contains object modules that support various system 
functions. 

5719-UT5 System Utility Programs 

Diskettes UT5001-2 contain the link editor, the utility programs and 
session manager programs. 

57 19-XX4 Program Preparation Facility 

Diskette XX4001 contains the EDX program preparation modules. 

Diskette XX4002 contains copy modules (DSOPEN,SETEOD, etc.) for 
inclusion in user application programs. 
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5719-LM7 Macro Library 



5719-LM7 is a library containing source macro definitions for the 
Event Driven Executive instruction set and system configuration state- 
ments. This macro library is used when assembling Event Driven 
Executive programs using the Series/1 Macro Assembler, 5719-ASA. 
It is not required, and cannot be used by the Event Driven language 
assembler $EDXASM, as $EDXASM is not a macro assembler. 



5740- LM4 Macro Library/Host 



This library is distributed on tape for installation on host S/370s, 
which will be used to assemble Event Driven Executive programs. 
Included are source macro definitions for the Event Driven Executive 
instruction set, as well as procedures/JCL prototypes to aid in host 
installation. 



STARTER SYSTEM INSTALLATION OVERVIEW 



Note: This discussion, and the "USER SYSTEM GENERATION" topic 
which follows, will be limited to the Basic Supervisor and Emulator, 
the Utility Programs, and the Program Preparation Facility. The Macro 
Library (5719-LM7) and Macro Library /Host {5740-LM4) licensed pro- 
grams will not be addressed. 

Installation is supported for: 

• 4962 Model 1 or 2 (9.3MB) 

• 4962 Model 1 F or 2F (9.3MB with fixed heads) 

• 4962 Model 3 or 4 (13.9MB) 
e 4963 Model 1 (29MB) 

o 4963 Model 1 F (23MB with fixed heads) 

• 4963 Model 2 (64MB) 

• 4963 Model 2F (58MB with fixed heads) 

An Event Driven Executive supervisor, to I PL, must reside in a data 
set named $EDXNUC. As shipped from PID, diskette XS3001 con- 
tains the starter supervisor in a data set named $EDXNUC. The first 
step in starter system installation requires that an I PL of the starter 
supervisor from diskette XS3001 be performed. Therefore, the Series/1 
on which the starter system is being installed 

MUST HAVE EITHER A 4964 Diskette Unit at hardware address 

X'02' 

OR A 4966 Diskette Magazine Unit at hard- 

ware address X'22' 

wired as an IPL device (PRIMARY or ALTERNATE). 

Note: If a 4966 is the IPL device, an IPL can be performed from disk- 
ette slot 1 only. 
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The object of starter system installation is to transfer the programs and 

O utilities supplied on the PID diskettes to a disk device. Among the 

programs transferred is $EDXNUC, the starter supervisor itself, so that 
an IPL can be performed from disk rather than diskette. Therefore, 
the Series/1 on which the starter system is being installed 

MUST HAVE EITHER A 4962 (any model) installed at hardware 

address X'03' 

OR A 4963 (any model) installed at hardware 

address X'48' 

wired as an IPL device (PRIMARY or ALTERNATE). In addition, the 
supplied supervisor assumes certain terminal device availability and 
hardware address assignments. The Series/1 on which the starter system 
is being installed 

MUST HAVE EITHER A TTY device at hardware address '00' 

OR A 4978 or 4979 Display at hardware 

address '04' 

AND MAY HAVE A 4974 Matrix Printer at hardware address 

x'or 

INSTALLING THE STARTER SYSTEM 

The procedures and instructions for installing the starter system 
received from PID are contained in the Program Directory which is 
shipped with the licensed program diskettes. As new versions or 
modification levels of the system are released, details of the installation 
process may change. This discussion is therefore limited to the major 
steps Involved. 

Step 1: IPL the Starter Supervisor from XS3001. When the starter 
supervisor is first loaded (IPL) and goes into execution, it searches for a 
4963 Disk at hardware address x'48'. If there is no 4963 Disk the 
supervisor searches for a 4962 Disk at address x'03'. If found, it reads 
the device ID (which contains information about the device) and alters 
the device data block (DDB) for the associated disk. 

Step 2: Initialize Logical Volumes. Before copying any data sets, a 
volume directory must be written on disk, volumes allocated and direc- 
tories created. Review the example in the $INITDSK portion of the 
Utilities Section of this document. See the Program Directory for 
recommended volume and directory sizes. 

Step 3: Copy Starter Supervisor, Utility Programs and System Support 
Modules. The utility program $C0PYUT1 is now used to copy the 
Starter Supervisor $EDXNUC on XS3001 to $EDXNUC on EDX002. 
Some of the system utility programs are also copied to EDX002. The 
system support modules are copied from diskette XS3003 to volume 
ASMLIBondisk. 
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Step 4: /PL Starter System from Disk and Complete Installation. The 
jPL SOURCE switch can now be set to IPL from disk, and the starter 
system again loaded, this time from the disk IPL volume. 

EDX002. $C0PYUT1 is again loaded, this time from EDX002 to 
which it was copied in the previous step. $C0PYUT1 is used to copy 
the remaining system programs on the PID diskettes to the various 
libraries on disk. 



Source 


Target 




Diskette 


Volume 


Description 


UT5001-2 


EDX002 


Remaining utilities and Session 
Manager modules 


XX4001 


ASM LIB 


Program Preparation modules 


XX4002 


ASM LIB 


Copy Code Modules 



The Starter Supervisor as supplied by IBM supports the following: 
64 KB Storage 

4962 Disk at address 03 

or 

4963 Disk at address 48 

4964 Diskette Unit at address 02 
4962 Diskette Magazine at address 22 
4978 or 4979 Display at address 04 
TTY Device at address 

3101 Model 2X in block mode 

at address 08 via asynchronous communications single line 
adapter 

at address 60 via asynchronous communications multiline 
adapter 

at address 68 via programmable communication adapter 

The Starter Supervisor does not support: 
Timers 
Sensor I/O 
Communications 
Interactive Debug 
Magnetic Tape 
Series/1 to Series/1 
General Purpose Interface Bus (GPIB) 
Spooling 
Floating Point Arithmetic 

Users who have different requirements from those provided by the 
Starter Supervisor must generate a tailored system that will satisfy 
their needs. 
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USER SYSTEM GENERATION 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
System Guide (SC34-1702) "System Generation." (ALL) 



SYSGEN OVERVIEW 



Allocate Required Data Sets 



Creating a supervisor tailored to a specific user configuration consists of 
the following tasks: 

1. Creating a set of system configuration statements reflecting the 
configuration of the system that the supervisor being generated is 
to run on. 

2. Selecting the supervisor object modules that are required to support 
the desired I/O devices and system features. 

3. Assembling the system configuration statements created in Step 1, 
above. 

4. Link editing the object module produced by the assembly in Step 
3 with the supervisor object modules selected in Step 2 to produce 
a tailored supervisor. 

In order to demonstrate how these tasks may be accomplished, the 
remainder of this section will go through each step of an actual system 
generation. 



After completion of starter system installation, the system programs are 
installed, but no user-allocated data sets have yet been defined. The 
system generation process requires the use of several system utility/pro- 
gram preparation programs that require data sets for use as work areas 
or input/output files. These data sets must be allocated by the user 
before SYSGEN can proceed. Data set allocation is done with the 
$DISKUT1 utility program. 
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> $L $DISKUT1 



$DISKUT1 37P, LP= 5700 
USING VOLUME EDX002 



COMMAND (?): |AL EDITWORK 200 D 



EDITWORK CREATED 



COMMAND (?): |AL ASMOBJ 250 D 



ASMOBJ CREATED 



COMMAND (?): |AL ASMWORK 250 
ASMWORK CREATED 




COMMAND (?): |AL SUPVLINK 600 D 
SUPVLINK CREATED 



COMMAND (?): |AL LEWORKl 400 D 
LEWORKl CREATED 



COMMAND (?): |AL LEW0RK2 150 D 
LEW0RK2 CREATED 




COMMAND (?): END 



$DISKUT1 ENDED 



Figure 15-1 . Allocate data sets 
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D EDITWORK is the name of a work file that will be required by 
$EDIT1N or $FSEDIT text editing utilities. 

Q These data sets are used by the assembler program $EDXASM. 
ASMOBJ is the data set in which the object module output of the 
assembler will be stored, and ASMWORK is an assembler work 
file. Note: In the Program Directory, it is suggested that you 
assemble the sample program CALCSRC to verify starter system 
installation. If you performed that step, ASMWORK and 
ASMOBJ have already been allocated, and need not be allocated 
here. 

Q SUPVLINK is the data set where the link editor, $LINK, will store 
the linked object module output from the supervisor link edit. 

D LEW0RK1 and LEW0RK2 are $LINK work data sets. 

EDIT SYSTEM CONFIGURATION STATEMENTS 

Before proceeding, you must know the configuration of the system you 
intend to run the supervisor on, and what features you want to support. 
You can generate a supervisor for a system other than the one used for 
SYSGEN, but for this discussion, assume the tailored supervisor being 
built is for the system you are now running on. 

$IOTEST 

( ) One of the operands you must specify in all of the system configuration 

^^ statements defining I/O devices is the device hardware address. The 

system utility program $IOTEST can be used to find out which devices 
are installed on your system and what their addresses are (Figure 15-2). 
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> $L SIOTEST 



$IOTEST 32P, LP= 8F00 

COMMAND (?): LD 

ACTUAL SERIES/ 1 HARDWARE CONFIGURATION 

ADDRESS DEVICE TYPE 

00 = TELETYPEWRITER ADAPTER 

01 = 4974 PRINTER 

02 = 4964 DISKETTE UNIT 

03 = 4962 DISK MDL3 

04 = 4979 DISPLAY STATION 
06 = 4978 DISPLAY STATION 
08 = SINGLE LINE ACCA 

21 = 4973 PRINTER 

40 = TIMER FEATURE 

41 = TIMER FEATURE 

Figure 15-2. $IOTEST LD 

In Figure 15-3 below, the LS command is used to list the hardware 
devices supported by the starter supervisor under which $IOTEST is 
running. 



COMMAND {?): LS 



HARDWARE DEVICES SUPPORTED BY THIS SUPERVISOR 
ADDRESS DEVICE TYPE 

00 = TELETYPEWRITER ADAPTER 

01 = 4973 PRINTER 

02 = 4964 DISKETTE UNIT 

03 = 4962 DISK MDL3 

04 = 4978 DISPLAY STATION 

08 = SINGLE LINE ACCA MODE 3101B 
22 = 4966 DISKETTE MAGAZINE UNIT 
60 = FOUR LINE ACCA MODE 3101B 
68 = FOUR LINE ACCA MODE 3101B 



COMMAND (?): END 



Figure 15-3. $IOTEST LS 
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By comparing Figures 15-2 and 15-3, you can see that the starter 
supervisor does not support the 4978 Display at address 06, the 4973 
printer at address 21 or the timers at address 40 and 41 . 

After the tailored system generation is complete and the new supervisor 
is loaded, the LS command of $IOTEST should result in a printout of 
supervisor-supported devices and address assignments, which matches 
the LD command output shown in Figure 15-2. 

Now you are ready to build a system configuration statement source 
file that reflects the I/O and system features you wish to support. This 
file can be created using either $EDIT1N or $FSEDIT. 

During the installation procedure, a data set reflecting the configuration 
statements used in generation the starter supervisor was copied to disk. 
The data set is $EDXDEF on volume ASM LIB. If you load the Text 
Editor, read the data set and list it, the contents would be as shown in 
Figure 15-4. 

OOOIO $eDXD6F CSECT 

0J020 DATA F»0» 

000 30 * 

00040 * FVENT DRIVEN EXECUTIVE - VERSION 3t MODI F ICAT ICN LEVEL 

00050 * 

00060 * THE FCLLOwING DEFINES THE STARTED SUPERVISOR AS SHIPPED ON THE 

00070 =:-- DISKETTE LA3ELEJ XS3001. FOR COMPLETE DESCRIPTIONS OF THESE 

OOOfiO =:= STATEMENTS OR ANY OTHER SYSTEM DEFINITION STAIEMENTSt REFER TO 

00090 ^.= THF EOX VERSION 3 SYSTEM GUIDE: SC34-I702 

00100 =:= 

00110 SYSTEM ST0RAGE = 64t.-1AXPR0G=10tPARTS=32 

0C120 DISK DEVlCc=4963-23f A0DRESS=48 

00130 DISK DEVICE=4964tADDRESS=02 

00140 DISK D£VICE=4966f A0DRESS=22»END=YES 

00150 SSYSLGG TERMINAL DEVICE=4978 ♦ AD0RESS=04tHDC0P Y= SSYSPRTR 

0ul60 SSYSLOGA TERMINAL OEVICE=TTY »AD0RESS=00 »CR0ELAY=4 t PAGS IZE=24 » C 

00170 !30T.M = 2 3»SCREEN=YES 

00130 $SYSL0G3 TERMINAL DFVICE=ACCA ,ADDRESS=03 ♦MaOE=31 Ol^t AOAPTER=S INGLE , C 

00190 3ITRATE=1200fRANGE=HIGH 

00200 SSYSLOGC TERMINAL OEV ICE = ACCA , ADOR ESS=6n ,yODE = 3 1 1 ^- » AD APTER=FOUR . C 

00210 rUTRATt=1200,RANGE=HIGH 

00220 SSYSLOGD TERMINAL OEV ICE =ACCA t AD0RESS = 68»MaDE = 31 01 3t CODTYP E=A SC I I . C 

00230 ATTN=1368»ADAPTER=FOURtLF=0A,CR=O0»PFl=lU6lf C 

002 40 3ITRATE=12 00»RANGE=HIGH 

00250 SSYSPRTR TERMINAL OEV ICE=4974 » ADDRESS=0 1 ,ENO=Y£S 

00260 $SYSCC.M CSECT 

00 2 70 QCz\ 

OOidO QC5 

00290 EC3 

00300 ECa 

00310 ENTRY SEOXPTCH 

00320 $EDXPTCH DATA 12BF»0« SYSTEM PATCH AREA 

00 3 30 END 

Figure 15-4. Contents of $EDXDEF 
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SYSTEM Statement 



The configuration statements shown match the hardware devices listed 
in Figure 15-3. You must edit this file to reflect your requirements 
(Figure 15-2). The 4963 DISK statement and $SYSLOG TERMINAL 
statement must be modified. The 4966 DISK statement, the 
$SYSLOGC and $SYSLOGD TERMINAL statements for the 4978 at 
address 06 and a TIMER statement must be added to complete the new 
correct configuration. The configuration statements are now discussed 
in more detail. 



The SYSTEM statement (statement 110 in Figure 15-4) defines a 64K 
system (STORAGE=64), with a maximum of 10 programs executing 
concurrently (MAXPROG=10). Now, assume that the system this 
supervisor is being generated for has 128K of storage. 

When a system has storage greater than 64K, multiple partitions must 
be defined, because of the way the software utilizes the hardware 
feature that addresses storage above 64K. Each partition defined Is a 
separate relocatable program area, just as the space between the end 
of the supervisor and the end of storage is a relocatable area in systems 
with 64K or less. 

The STORAGE= operand in the SYSTEM statement must be changed 
to STORAGE-128. Up to 8 partitions may be defined, and for this 
example, assume that 3 partitions are desired. The MAXPROG= oper- 
and will now be changed to MAXPROG=( 10,1 0,10), with each sublist 
element in the operand list corresponding to the maximum number 
of programs allowed to execute in partition 1, partition 2, and parti- 
tion 3, respectively. 10 programs in concurrent execution In any one 
partition is enough to exceed most application requirements, but this 
can be coded to meet your own application needs. {Note: All partitions 
do not have to have the same MAXPROG= value; MAXPROG=(6,3,10), 
for example, is valid.) 

When using multiple partitions, a third operand, PARTS= must be coded. 
PARTS= is used to specify the size of each partition. Partitions can be 
up to 64K in size with the exception of Partition 1 which is restricted 
to 64K minus the size of the supervisor. 

Partitions are defined in increments of 2K blocks (2048 bytes each). 
The first 64K of storage is represented by 32 such 2K blocks. If we 
estimate our supervisor to be 40K, we have 88K or 44-2K blocks of 
storage available for partitions. The largest size for partition one would 
be24K(64-40K). 

Let's assume in our system we desire partitions of 16, 32, and 40K. 
Using the text editor, the SYSTEM statement would be modified to 

SYSTEM ST0RAGE=128,MAX PR0G=(10,10,10) ,PARTS=(8,16,20) 
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TIMER Statement 



DISK Statements 



One of the devices to be supported by the new supervisor is Timers. 
The starter supervisor has no TIMER statement, so one must be added 
using the INSERT function of the Text Editor. 

Although both timers will be supported, only one TIMER statement is 
entered. The system knows that the two timers have contiguous 
addresses, so a single TIMER statement specifying the address of the 
first timer is all that is required. 

Note: For 4952 processors, the timer is part of the processor, not a 
feature and no TIMER system configuration statement is used. 



The DISK configuration statement is used to define disk and diskette 
devices to the system. The configuration file (Figure 15-7) shows 
3 DISK statements (4963 Model 23, 4964 Diskette and 4966 Diskette 
Magazine). Based on our hardware configuration, we must change the 
Disk to 4962-3 and delete the 4966 Diskette Magazine DISK statement. 

To run disk/diskette devices, the system generates a system disk task 
which it attaches to perform disk or diskette I/O. As with any other 
task, the system disk task is not reentrant; it may only be attached by 
one user at a time. When multiple direct access devices are supported, 
where I/O requests to the high data rate disk could be suspended, wait- 
ing for the disk task to complete a request for one of the relatively 
slower diskette devices. 

By coding TASK=YES in the DISK statements defining the diskette 
devices, a separate task is generated for each device. 

After editing the configuration file, the DISK statements would be: 

DISK DEVICE = 4962-3, ADDRESS=03 

DISK DEVICE = 4964,ADDRESS=02,TASK=YES,END=YES 



System Installation 15-11 



TERMINAL Statement 



Figure 15-5 below shows a list of the TERMINAL system configura- 
tion statements for the supplied supervisor. 



00150 SSYSLOG TERMINAL 0E\/ICE=4973» A0DRESS=04»HDC0PY= SSYSPRTR 

00160 $SYSLOGA TERMINAL OEV ICE=TTY »ADDRESS=00 »CRDELAY= +» PAGSI ZE =24» C 

00170 30TM=23tSCREEN=YES 

00180 ISYSLOGa TERMINAL DEVICE=ACCA» A0DRESS=08 ♦MaDE=3lOI3 t AOAPTER= SI NGLE , C 

00190 8irRATE=1200,RANGE=HIGH 

00200 tSYSLOGC TERMINAL DEVICE=ACCAf ADDRESS=60f M3DE=3101B» AOAPTER=FOUR t > C 

00210 BITRATE=1200,RANGE=HIGH 

00220 JSYSLOGC TERMINAL OEV ICE=ACCA» ADDRESS=68,M0DE=3101Bf COOTYP E=ASCI I ♦ C 

00230 ATTN=1E68»A0APTER=F0UR»LF=0A,CR=0D»PF1=136I» C 

00240 3irRATE=1200fRANGE=HIGH 

00250 SSYSPRTR TERMINAL DEV ICE=4974» ADORES S=01 ,ENO=YES 

Figure 15-5. Starter TERMINAL statements 

In a multiple partition system, terminals are assigned to partitions. 
When a terminal is assigned to a partition, operator commands invoked 
from that terminal are directed to the assigned partition. See the 
"OPERATOR COMMANDS" topic In "Section 14. System Utilities" 
for a discussion on how terminal/partition assignments may be changed 
online. For this SYSGEN, $SYSLOG (statement 150) will be assigned 
to partition 1 , and the TTY device (statements 160 and 170) will be 
assigned to partition 2. In statement 170 (the continuation of statement 
160), the SCREEN= operand is coded as SCREEN=YES. This indicates 
that the supplied supervisor assumes that the TTY is an electronic 
display screen device. 

SCREEN=YES causes a pause after every 24 lines of output, so that the 
data on the screen can be read by the operator. To display the next 24 
lines, the operator must press the ENTER key. 

Assume the TTY device on this system is not an electronic display 
screen device, but Is a hardcopy TTY with continuous forms. The 
pause after every 24 lines is not required, and is in fact an annoyance, 
so SCREEN=YES should be changed to SCREEN=NO. 

Using the delete function of the Text Editor, the $SYSLOG and 
$SYSLOGD statements can be removed from the file. 

Next, the 4978 Display at address 06 and the 4973 Printer, neither of 
which is supported by the supplied supervisor, are added to the 
TERMINAL definitions. The 4978 is named DSPLY1, and the 4973 
LINEPRTR. The names used are not predefined; you must name the 
devices anything you wish. 
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After editing the configuration file, the TERMINAL statements would 
be: 

00150 SSYSLOG TERMINAL OEV ICe=4979 ♦ ADOR ESS=0^»HDCOPY= SSYSPRTR ,P ART=2 

00151 DSPLYl TERMINAL OEV ICE=4973 » AD0RESS=06 t HOCOPY= tSYSPRTR t PART=3 

00160 SSYSLOGA TERMINAL OEVICE=TTY , ADORESS=00 t CR0ELAY=4» PAGS IZE=24» C 

00170 aOTK=23fSCREEN=YES 

00180 $SYSLOGB TERMINAL OEVICE=ACCA f ADDRESS=08 tM0DE=3I0IBf ADAPTER=S INGLE» C 
00190 aiTRATE=9600fRANGE=HIGH 

00250 LINEPRTR TERMINAL 0EVICE=4973f AD0RESS=2 I 

00251 tSYSPRTR TERMINAL DEVICE=497^ t ADORESS=OI »END=YeS 

Figure 15-6. Modified TERMINAL statements 



System Communications Area 



The system communications area is the area known by the system 
global name $SYSCOM. It is used for communication and synchroni- 
zation between programs. The supplied supervisor already has a 128 
word area called $EDXPTCH, which can be used as part of $SYSCOM. 

For this example, $SYSCOM will consist of two QCBs and two ECBs, 
plus the already existing 128 word area, $EDXPTCH. 

This completes the modifications to the system configuration source 
file. Figure 15-7 provides a listing of the changes made for the hardware 
specified earlier. 
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00010 
00020 
00030 
00040 
00050 
00060 
00070 
00080 
OOO'^yO 
OOIOO 
00 1 1 
00120 
00130 
00140 
00150 
00160 
00170 
00 I 80 
00190 
00200 
00210 
002 20 
00230 
00240 
00250 
00260 
00270 
00 2 SO 
00290 
00 300 
00310 
00320 
00330 



$POXDeF 



CSECT 
DATA 



F«0' 



* EVENT DRIVEN EXECUTIVE - VERSION 3, MODIFICATION LEVEL 
« 

* THE FOLLOWING DEFINES THE STARTER SUPERVISOR AS SHIPPED ON THE 

* DISKETTE LA3ELE0 XS3001. FOR COMPLETE DESCRIPTIONS OF THESE 

* STATEMENTS OR ANY OTHER SYSTEM DEFINITION STATFMENTSt REFER TO 
« THF EDX VERSION 3 SYSTEM GUIDE: SC34-1702 



tSYSLOJ 
tSYSLOGA 

iSYSLOGd 

SSYSLOGC 

ISYSLOGD 



JSYSPRTR 

$ SYS COM 



$EDXPTCH 



SYSTEM STORAG 
DIJK DEVICE 
DISK DEVICE 
0I5K DEVICE 
TERMINAL OEV 
TERMINAL DEV 

^3QTM = 23 
TERMINAL DEV 

BITRATE 
TERMINAL DEV 

BITRATE 
TERMINAL DEV 

ATTN=113 

BITRATE 
TERMINAL DEV 
CStCT 
QC^ 

EC^ 

FCR 

ENTRY $ED 

DATA 126 

END 



E=64»MAXPR0G=10fPARTS=32 

=4963-2 3f ADORES S=48 

=4964f ADDRESS=02 

=4966,ADDRE5S=22fEN0=YFS 

ICE=4979f ADDRESS =04 »HDCOPY=$SYS PRTR 

ICE=TTYfA0DRESS=00»CR0ELAY=4»PAGSIZE=24 

.SCRFFN=YFS 



fSCREEN=YES 

ICE=ACCA»A0DRESS=0 8fM00E=3101Bf ADAPTER=SINGLEf 

=1200,RANGE=HIGH 

At A00RESS=60fM0DE=3131B»A0APTER=F0URf 

ANGE=HIGH 

AtAD0RESS=6 8»M00E=31313tC00TYPE=ASCII» 

TER=FOURfLF=0A,CR=0n,PFl=lH61f 

ANr,F=HIGH 



1 v-u.— «v,v-*^ T «u'i-'r\ujj 

=1200,RANGE=HIGH 

IC E =ACC A f ADORES S = 60f MODE =31 31B»A0APTER= FOUR f 

=1200fRANGE=HIGH 

ICE=ACC 

6af ADAP . 

=1200,RANGE=HIGH 

ICE =4974* ADORES S=01fEN0=yES 



XPTCH 
F»0» 



SYSTEM PATCH AREA 



Figure 15-7. Starter configuration 



The completed, edited file must be stored in a data set $EDXDEFS on 
volume EDX002. 



ASMLIB 



EDX002 





$FSEDIT 



EDX002 




Figure 15-8. Configuration file update 
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SELECT SUPERVISOR SUPPORT MODULES 



00010 
00020 
00030 

000 30 
00140 
00150 
00160 
00170 

001 bO 
00190 
00200 
00260 
00270 
00280 

002 90 
00 350 
00410 
00420 
00430 
00440 
00450 
00460 
0C470 
0043 
00490 
00 5 00 
00510 
00520 
00530 
00540 
00550 
00560 
00570 
00630 
00640 
00650 
0u660 
00720 
00780 
00 790 
00850 
00860 
00870 



The next step is to choose the supervisor support object modules 
required to support your configuration. These object modules are 
specified in link editor INCLUDE statements, which reside in a link 
edit control statement file. 

As with the system configuration statements, you do not have to enter 
each INCLUDE record you need. Data set $LNKCNTL on volume 
ASM LIB contains all possible supervisor INCLUDE statements. You 
must choose those required for your configuration. Figure 1 5-9 is a 
listing of the $LINKCNTL data set that shows the modules that were 
included in the generation of the starter supervisor. The statements 
that have an asterisk in Column 1 are understood by the link editor to 
be comments rather than a control record. 



* EVENT OHIVEN EXtCUTIVF: - VTRSIO'VJ 3» KOOIFICATION LFVEL 



OUTPUT 

INCLUDF 

INCLUDE 

INCLUCF 

INCLUOF 

INCLUOt 

IMCLUDf? 

IMCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUCF 

INCLUDE 

INCLUOF 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUCF 

INCLUDE 

INCLUDE 



SUPVLINK 
FOXSYStX 
ASMJBJ,E 
FDXSVCXf 

eo.xsvcxu 

SOBUG.'nUC 
EOXALUfX 
EDXSTART 
DIS<IO,X 
049624»X 
D4963A»X 
04966A,X 
D4969Af X 
FOXTICJtX 
EDXTICUf 
tOXTERMu 
FOXTRHQU 
I0S4979, 
IUS4979U 
I0S4974» 
IGS4974U 
lOSTERV.f 
lUSTTYfX 
lOSACCA, 
IOS3101, 
lOSSlSl, 
lOSGPIBf 
I0S4013, 
I0S2741f 
ICJSVIRT, 
TRASCIIt 
TRE^ASCf 
TRE3CDf X 
TRCRSPfX 
ICSPOOLt 
EDXTIME^< 
EDXTIMR2 
BSCAM,XS 
SSCAMUf X 
TPCOM,XS 



♦20X002 

S3002 

DX002 

XS3002 

»XS3002 

»XS3002 

S3 Of) 2 

♦XS3002 

S300 2 

S30U2 

S3 00 2 

S300? 

S30iJ2 

S3002 

XS3002 

♦XS3002 

♦XS3002 

XS3002 

tXS3002 

XS3002 

»XS3002 

XS3002 

S3002 

XS3002 

XS30O2 

XS3002 

XS3002 

XS3J02 

XS3002 

X53002 

X53002 

XS3002 

S3002 

S3002 

XS3002 

fXS3002 

♦XS3002 

3002 

S3002 

3002 



-.• J -.• 
*0* 
«0t 

♦ 0, 

♦ 0* 

%•- . ■ »^' 

♦ M* 

*lt 
♦ I, 

*u 

*1 t 

*** *ji 

*2* 
*M* 
*3« 
♦M, 
«M* 
*.M* 

*M* 
*M, 
*4, 
*3, 
«S« 

♦ M* 
«6* 

♦ 6* 
*7, 
*7« 

«*« O ''- 



ENTRY=$START 

SYSTF.^i TABLES AND WORK AREAS 
OUTPUT FROM USER SYSTEM GENERATION 
K* TASK SUPERVISOR (XL) 
L* TASK SUPERVISOR (UN-XL) 
RESIDENT SOERUG SUPPORT 
EDL INSTRUCTION EMULATOR 
INITULIZATION ^ ERROR HANDLER 
BASIC .OISK(tTTh) SUPPORT 
4962/4964 OISK(eTTE) SUPPORT 
4963 SUBSYSTEM SUPPORT 
4966 MAGAZINE SUPPORT 
3ASIC TAPE SUPPORT 
BASIC TERMINAL SUPPtJRT (XL) 
BASIC TERMINAL SUPPORT (UN^XL) 
ENOT/DEgT L TERMINAL QUEUEING (XL) 

C TERMINAL QUEUEING (UN-XL) 



K* 
L* 
K* 
L« 
K* 
L* 
K* 
L* 



0* 



N« 
P* 
P* 



ENQT/DEyT 
4970/4979 
497ti/4979 
4973/4974 
4973/4974 
REQUIRED 



OISPLAY 
DISPLAY 
PRINTER 
PRINTER 
FOR TTY, 



SUPPORT 
SUPPORT 
SUPPORT 
SUPPORT 



(XL) 
(UN-XL) 
(XL) 
(UN-XL) 



ACCAf 4013 L 2741 



K* 
L* 



AS'' 33/35 TELETYPEWRITER SUPPORT 

ASCII ACCA TERMINAL SUPPORT 

3101 i^LOCK MODE SUPPORT 

SERIES/1 - SERIES/1 SUPPORT 

GPI3 SUPPORT 

DIGITAL I/O TERMINAL SUPPORT 

2741 TERMINAL SUPPORT 

VIRTUAL TERMINAL SUPPORT 

TELETYPEWRITER TRANSLATION 

MIRROR IMAGE ASCII TRANSLATION 

2741 EBDC TRANSLATION 

2741 CORRESPONDENCE TRANSLATION 

SPOOLING SUPPORT 

4953/4955 TIMER (7840) SUPPORT 

4952 TIMER SUPPORT 

BISYNC CGMM. ACCESS SUPPORT (XL) 

BISYNC COMM. ACCESS SUPPORT (UN-XL) 

HOST COMMUNICATION SUPPORT 



Figure 15-9. Starter Link file (1 of 2) 
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0U930 


* 


INCLUDE 


S3CON',XS30C2 


♦ 9* 


00940 


« 


INCLUDE 


IOLOA0ERtXS3OO2 


*9»K* 


00950 


* 


INCLUDE 


IOLOAORUfXS3002 


*9fL« 


00960 


« 


INCLUDE 


SbAItXS3002 


*M* 


00970 


« 


INCLUDE 


SBAij,XS3002 


«M* 


00980 


* 


INCLUDE 


SBDID0»XS30U2 


*M* 


00990 


V 


INCLUDE 


S3PI,XS3002 


♦M* 


01050 




INCLUDE 


I0SEXI0,XS3002 


:::M* 


OHIO 




INCLUDE 


SYSL0GtXS3002 




01120 


* 


INCLUDE 


NaSYSLOG»XS3002 


*A« 


01130 




INCLUDE 


CIRCEVUFFfXS3002 


*fi* 


01190 


* 


INCLUDE 


RLOADGRtXS3002 


*C,K« 


01200 




INCLUDE 


HLOADcRUf XS^0C2 


'l^CtL* 


01210 




INCLUDE 


EDXFL0AT,XS3002 


*D* 


01220 




INCLUDE 


N0FL0Ar,XS3002 


*D« 


01230 


<« 


INCLUDE 


EBFLCVT,XS3002 


<:[:* 


01240 




INCLUDE 


QUEUFI0,XS3U02 


«F* 


01300 




INCLUDF 


EDXINITtXS3002 


«H« 


01310 




INCLUDE 


0IS^INIT,XS3002 


*.M* 


01320 


* 


INCLUDE 


TAPElNlTfXS3002 


♦M* 


01330 




INCLUDE 


L0A0INTTfXS3002 


*c* 


01340 




INCLUDE 


RW4963I0»XS300? 




01350 




INCLUDE 


Ti5RMINIT»XS3002 


«i« 


01360 




INCLUDF 


Irv)IT4973fXS3002 


♦M* 


01370 




IMCLUDE 


TMIT4013,XS3002 


*>i* 


01330 




INCLUDE 


$ACLA«AM,XS3002 




01390 




INCuUDE 


9SCINIT»XS3002 


♦ 7« 


01400 


♦ 


INCLUDE 


TPINIT,XS30:j2 


♦ 3 -•;: 


C1410 


* 


r«JCLUDE 


TlM;<INIT,XS3n02 


♦ 6^:= 


01420 


♦ 


INCLUDE 


CLOi<lNIT,XS3002 


*6« 


01430 


-•• 


INCLUDE 


saicjiNirfXS3002 


*;^=:s 


01440 


« 


INCLUDE 


FXIOINIT»XS3002 


*M* 


01450 


* 


INCLUDI-: 


S1S1INIT,XS3002 


*y, j* 


02060 




END 







BASIC SENSOR I/O SUPPORT 

SENSO.^ I/O DEVICE OPEN (XL) 

SENSOR I/O IJEVICE OPEN (UN-XL) 

ANALOG INPUT SUPPORT 

ANALOG OUTPUT SUPPORT 

DIGITAL INPUT/OUTPUT SUPPORT 

PROCESS INTrfRRUPT SUPPORT 

EXIO DEVICE CONTROL SUPPORT 

I/O ERROR LOGGING 

NO, I/O cRROR LOGGING 

PROGRAM/MACHINE CHECK LOGGING 

RELOCATING PROGRAM LOAOFR (XL) 

RELOCATING PROGRAM LOADER (UN-XL) 

FLOATING POINT ARITHMETIC 

FOR SYSTEMS WITHOUT FLOATING POINT 

E.^CDIC/FLOATING POINT CONV. 

CUEUE PROCESSING SUPPORT 

SUPERVISOR INITIALIZATION 

DISK(ETTE) INITIALIZATION 

TAPt INITIALIZATION 

PROGRAM LOADER INITIALIZATION 

4963 FIXED HEAD REFRESH SUPPORT 

TERMINAL INITIALIZATION 

497ij DISPLAY INITIALIZATION 

DIGITAL I/O TERMINAL INITIALIZATION 

ACCA MULTI-LINE ADAPTER RA« LOAD 

BISYNC (OSCAM) INITIALIZATION 

HCF (TPCPM) INITIALIZATION 

4953/4955 TIMER INITIALIZATION 

4952 TIMER INITIALIZATION 

SENSOR I/O INITIALIZATION 

EXIO INITIALIZATION 

SlSl INITIALIZATION 



Figure 15-9. Starter Link file (2 of 2) 



Instead of deleting undesired INCLUDE statements, it is preferable to 
insert an asterisk in column 1 . The asterisk causes the link editor to 
treat the statement as a comment statement rather than a control 
record. This gives you a record of what support you have decided to 
leave out, which can be helpful if problems develop with the generated 
supervisor. 

The support available for some system functions is provided in two 
versions— untranslated or translated— specified on the INCLUDE state- 
ment comments as UN-XL and XL respectively. The untranslated 
modules support systems with a memory of 64K or less while trans- 
lated modules support systems with greater than 64K of memory. 
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The completed INCLUDE file is shown in Figure 15-10. Those state- 
ments with asterisks in column 1 are for features that are not desired 
or for I/O devices not installed. 



00020 
00030 
000 9 
001^0 
00150 
00160 
00170 
00130 
00190 
002 00 
00260 
00270 
00280 
00290 
00350 
00410 
00420 
00430 
00440 
00450 
00460 
00470 
00480 
00490 
00500 
00510 
00520 
00530 
00540 
00550 
00560 
00570 
00630 
00640 
00650 
00660 
00720 
00780 
00790 
00950 
00860 
00930 
00940 
00950 
00960 
00970 
00980 
00990 
01050 
OHIO 
01120 
01130 
01190 
01200 
01210 
Q1220 



* EVENT DRIVEN EXECUTIVE - VERSION 3» MODIFICATION LEVEL 



OUTPUT SUPVLINi<fEDX002 

I.NCLUOE EDXSYSfXS3002 

INCLUDE ASMOBJf EDX0U2 

INCLUDE EDXSVCX,XS3002 

* INCLUDE EDXSVCXUiXS3002 *0»L* 
INCLUDE S0BUGNUC»XS3002 -^G« 
INCLUDE E0XALUfXS3002 «0* 
INCLUDE E0XSTARTfXS3002 *0* 

' INCLUDE 0ISKIO,XS3O02 *M* 

INCLUDE D49624»XS3002 *M* 

* INCLUDE D4963A»XS3002 «M* 

* INCLUDE Dh966A»XS3002 *M* 
« INCLUDE D4969A,XS3002 «M« 

INCLUDE EDXTI0fXS3002 *ltK« 

« INCLUDE EDXTI0UfXS3002 *1»L* 

INCLUDE E0XTERMQ,XS3002 *lfK« 

* INCLUDE EDXTRMQUfXS3002 *I,L* 
INCLUDE I0S4979,XS3002 *MfK« 

« INCLUDE I0S4979U»X53002 *M,L* 

INCLUDE IOS4974fXS3002 *M,K« 

* INCLUDE I0S4974UfXS3002 *MfL* 
INCLUDE I0ST6RM,XS3002 *2« 
INCLUDE IOSTTY,XS3002 ^.^l* 
INCLUDE I0SACCA,XS3002 *3* 
INCLUDE I0S3101fXS3002 *M,0« 

« INCLUDE I0SSlSlfXS3a02 *M* 

* INCLUDE I0SGPIB,XS3002 <=M« 
« INCLUDE IOS4013fXS30O2 *M* 

* INCLUDE iaS2741»XS3002 *M« 

« INCLUDE IQSVIRTfXS3002 =!--M»N« 

INCLUDE TRASCII,XS3002 *4fP* 

INCLUDE TREBASC»XS3002 *3»P* 

* INCLUDE TREBC0,XS3002 *5* 

* INCLUDE TKCRSP,XS3002 *5* 
INCLUDE I0SP00L»XS3002 *«* 
INCLUDE EOXTIMERfXS3002 *6* 

« INCLUDE EDXTIMR2»XS3002 *6* 

* INCLUDE BSCAM»XS3002 *7»K* 
« INCLUDE BSCAMU»XS3002 «7fL* 

* INCLUDE SBCOMfXS3002 «9* 

« INCLUDE I0LOADER»XS3002 «9fK* 

- INCLUDE IQLOADRU»XS3002 «9fL* 

« INCLUDE SflAIfXS30C2 *M* 

« INCLUDE SBAO,XS3002 *M* 

* INCLUDE SBDID0,XS3O02 *.M* 
« INCLUDE SBPIfXS3002 *M* 
« INCLUDE I0S6XI0fXS3002 *M* 

INCLUDE SYSL0GfXS3002 *A* 

« INCLUDE N0SYSL0G»XS3C02 *A* 

INCLUDE CIRCBUFF»XS3002 *B* 

INCLUDE, P.L0ADER»XS3002 *CfK« 

* INCLUDE RL0A0ERUfXS3002 -CtL* 
INCLUDE E0XFL0ATfXS3002 «D- 

« INCLUDE N0FL0ATtXS3002 *D* 



ENTRY=$START 
*0* SYSTEM TABLES AND WORK AREAS 
*0« OUTPUT FROM, USER SYSTEM GENERATION 
*0fK* TASK SUPERVISOR (XL) 

TASK SUPERVISOR (UN-XL) 

RESIDENT SDEBUG SUPPORT 

EOL INSTRUCTION EMULATOR 

INITIALIZATION & ERROR HANDLER 

BASIC DISK(ETTE) SUPPORT 

4962/4964 OISK(ETTE) SUPPORT 

4963 SUBSYSTEM SUPPORT 

4966 MAGAZINE SUPPORT 

BASIC TAPE SUPPORT 

BASIC TERMINAL SUPPORT 

BASIC TERMINAL SUPPORT 

ENQT/DEQT 

ENQT/DEQT 

4973/4979 

4973/4979 DISPLAY 

4973/4974 PRINTER 

4973/4974 PRINTER 

REQUIRED FOR TTY» 



(XL) 
(UN-XL) 
C TERMINAL QUEUEING (XL) 
& TERMINAL QUEUEING (UN-XL) 
DISPLAY SUPPORT (XL) 

SUPPORT (UN-XL) 
SUPPORT (XL) 
SUPPORT (UN-XL) 
ACCAf 4013 C 2741 



ASR 33/35 TELETYPEWRITER SUPPORT 

ASCII ACCA TERMINAL SUPPORT 

3101 BLOCK MODE SUPPORT 

SERIES/1 - SERIES/1 SUPPORT 

GPIb SUPPORT 

DIGITAL I/O TERMINAL SUPPORT 

2741 TERMINAL SUPPORT 

VIRTUAL TERMINAL SUPPORT 

TELETYPEWRITER TRANSLATION 

MIRROR IMAGE ASCII TRANSLATION 

2741 EBDC TRANSLATION 

2741 CORRESPONDENCE TRANSLATION 

SPOOLING SUPPORT 

4953/4955 TIMER (7840) SUPPORT 

4952 TIMER SUPPORT 

BISYNC COMM. ACCESS SUPPORT (XL) 

BISYNC COMM. ACCESS SUPPORT (UN-XL) 

BASIC SENSOR I/O SUPPORT 

SENSOR I/O DEVICE OPEN (XL) 

SENSOR I/J OEVICF OPEN (UN-XL) 

ANALOG INPUT SUPPORT 

ANALOG OUTPUT SUPPORT 

DIGITAL INPUT/OUTPUT SUPPORT 

PROCESS INTERRUPT SUPPORT 

EXIO DEVICE CONTROL SUPPORT 

I/O ERROR LOGGING 

NO I/O ERROR LOGGING 

PROGRAM/MACHINE CHECK LOGGING 

RELOCATING PROGRAM LOADER (XL) 

RELOCATING PROGRAM LOADER (UN-XL) 

FLOATING POINT ARITHMETIC 

FOR SYSTEMS WITHOUT FLOATING POINT 



Figure 15-10. Updated Link file (1 of 2) 



System Installation 15-17 



01230 




INCLUDE 


EBFLCVTfXS3002 


♦ E* 


EBCOIC/FLOATING POINT CONV. 


01240 




INCLUDE 


QUEUEI0fXS3002 


«F* 


QUEUE PROCESSING SUPPORT 


01300 




INCLUDE 


EDXINIT,XS3002 


♦ H* 


SUPERVISOR INITIALIZATION 


01310 




INCLUDE 


OlSKINITf XS3002 


«M* 


DISK(ETTE) INITIALIZATION 


01320 


« 


INCLUDE 


TAPEINIT,XS3002 


*M* 


TAPE INITIALIZATION 


01330 




INCLUDE 


LOAOINir»XS3002 


«C* 


PROGRAM LOADER INITIALIZATION 


01340 


<s 


INCLUDE 


RW4963ID»XSi002 


*M* 


4963 FIXED HEAD REFRESH SUPPORT 


01350 




INCLUDE 


TERMINIT,XS3002 


♦ 1* 


TERMINAL INITIALIZATION 


01360 




IINiCLUCE 


INIT4978tXS3002 


♦.<♦ 


4978 DISPLAY INITIALIZATION 


01370 


^* 


INCLUDE 


INIT4013»XS3002 


*f^1* 


DIGITAL I/O TERMINAL INITIALIZATION 


01380 


♦ 


INCLUDE 


$ACCARAMf XS3002 


*3« 


ACCA MULTI-LINE ADAPTER RAM LOAD 


01390 


* 


INCLUDE 


8SCIN1T,XS3002 


«7* 


BISYNC (BSCAV) INITIALIZATION 


01400 


•.* 


INCLUDE 


TPINIT,XS3002 


*b* 


HCF (TPCOM) INITIALIZATION 


01410 




INCLUDE 


TIMRINIIf XS3002 


*6* 


4953/4935 TIMER INITIALIZATION 


01420 


« 


INCLUDE 


CLOKlNlTfXS3002 


♦ 6* 


4952 TIMER INITIALIZATION 


01430 


* 


INCLUDE 


S3lLlTNITfXS3002 


♦ M* 


SENSOR I/O INITIALIZATION 


01440 


« 


INCLUDE 


cXI3I.\ITfXS3002 


*M* 


EXIG PvilTtALIZATION 


01450 


* 


INCLUDE 


SlSlI\irtXS3002 


*?,w* 


SlSl INITIALIZATION 


02060 




END 









V..^' 



Figure 15-10. Updated Link file (2 of 2) 



The completed file is now saved to the LINKCNTL data set on 
volume EDX002. 

Figure 15-1 1 summarizes operations up to this point. 



ASMLIB 




Figure 15-11. Link file update 
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EDIT $JOBUTIL PROCEDURE FILE 

Now that $EDXDEFS contains your system configuration statements, 
and LINKCNTL contains the edited INCLUDE file, you are ready to 
assemble the configuration statements, and link edit the resulting object 
module with the supervisor support object modules specified in 
LINKCNTL. The linked object module will then be formatted by the 
$UPDATE utility to form an executable supervisor. 

The assemble, link, and formatting steps will be performed under 
control of the job stream processing utility $JOBUTI L. You could 
load the assembler $EDXASM, provide the data set names required 
yourself, and do the assembly, then in turn do the same for $LINK and 
$UPDATE, but using $JOBUTIL, all three steps may be accomplished 
with a single entry. 

$JOBUTI L operation is controlled by a procedure file of job control 
statements. For SYSGEN, a procedure file named $SUPPREP is 
supplied on volume ASM LIB. Figure 15-12 presents a listing of that 
procedure file. 

If, when you allocated data sets at the beginning of SYSGEN, you had 
used other than the names/volumes recommended, you would now have 
to edit this procedure file to reflect the names/volumes you used. 

00010 « 

00020 « EVFNT DRIVEN EXECUTIVE - VERSION 3f VOOIF ICATION LEVEL 

00030 « 

00040 LOG $SYSPRTR 

00050 JOB SSUPPREP 

00060 REMARK «* ENTER -GO- AFTER -Xb3002- HAS BEEN VARIED ONLINE -* 

00070 REMARK ** AND AFTER THE FOLLOWING "EMaEKS «* 

00080 REMARK *« HAVE BEEN ALLOCATED ON VOLUME EDX002: ** 

00090 REMARK *« ASMwORK , ASMUBJtLE WORKl ,LEK0RK2, SUPVLINK *':= 

OOIOO KEVARK ** - SIZES AS PRESCRIDED IN PROGRAM DIRECTJRY - -* 

00110 PAUSE 

00120 PROGRA" $EOX ASM» ASMLI B EOX ASSEMBLtR PROGRAM 

00130 NOMSG 

001*^0 PARM 

00150 DS $FDX0EFSf£0X002 CONFIGURATION STATEME'vlTS DATA SET 

0015C DS ASMW0RKfEnx002 ASSEMBLER WORK DATA SET 

00170 DS ASM0BJtEJX002 OBJECT OUTPUT DATA SET 

00150 rXEC 

00190 JU"P cN0J0B»GT,4 

OOZOC PRGGF'AW $L INK, EDX002 LINK EDITOR PROGRAM 

00210 \0'^SG 

0J220 PARM iSYSPRTR 

00230 OS LINKCNTL»EDX002 LINK EDITOR CONTROL STATEMENTS 

00240 DS LEW0RK1,EDX002 LINK EDITOR WORK DATA SET 

00250 DS LEU'ORK2»EDX002 LINK EDITOR WORK OATA SET 

00750 EXEC 

00270 JU**.? EN0J08fGT,4 

00280 PROGRAM SUPOATEt EDX002 UPDATE (FORMAT) PROGRAM 

00290 N0M5G 

00300 PARM SSYSPRTR SUPVL INKt EDX002 SEDXNUCT, E0X002 YES 

00310 EXEC 

0032C LABEL ENDJOB 

Of! 330 hOJ 

Figure 15-12. $J0BUTIL procedure 
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For example, if you had called the assembler work file ASMWRK1 
instead of ASMWORK, you would have to change the name in the DS 
statement number 160. 

All files allocated for this SYSGEN used the recommended names and 
volumes, so the editor work data set is saved in the data set SUPPREPS 
on EDX002. The editing portion of SYSGEN is complete, and is 
summarized in Figure 15-13. 



v.. 



ASMLIB 




Figure 15-13. Procedure file update 



Note: Because there were no changes required in the $JOBUTIL pro- 
cedure file, the transfer of $SUPPREP on ASMLIB to SUPPREPS on 
EDX002 could have been accomplished using $COPY or $C0PYUT1, 
rather than with the READ and WRITE text editor commands. 



ASSEMBLE/LINK/FORMAT 



To assemble, link edit, and format the tailored supervisor, load 
$JOBUTIL, and supply the name of your procedure file, as illustrated 
in Figure 15-14. 



$L $JOBUTIL 



4P, LP =6000 



> 

$JOBUTIL 

ENTER PROCEDURE (NAME, VOLUME) : [SUPPREPS,EDX002 

$JOBUTIL ENDED 

Figure 15-14. $J0BUTIL 
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The procedure file has specified $SYSPRTR as the log device, so the 
first thing that happens is that the procedure file statements controlling 
the assembly operation print out on the system printer (see Appendix 
A, Figure A-1 ). $JOBUTI L loads the assembler, $EDXASM, which 
assembles your system configuration source file, $EDXDEFS. 



SJOBUTIL 
{EDX002) 




Figure 15-15. SEDXASM 



The resulting object module is stored in data file ASMOBJ on volume 
EDX002, which you created. The listing produced as a result of the 
assembly prints out on the system printer, preceded by assembler 
statistics (see Appendix A, Figure A-2), 

Next, $JOBUTI L loads the link editor, $LINK. (Appendix A, Figure 
A-3.) Using the object module from the assembly (ASMOBJ) and the 
file of link control records (INCLUDE statements) you stored in 
LINKCNTL, the $LINK program brings in the supervisor object modules 
specified in LINKCNTL and link edits them with the system control 
blocks generated by the assembly (ASMOBJ object module). 
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$JOBUTIL 
(EDX002) 




Figure 15-16, SLINK 



The data set SUPVLINK, which you allocated for link edit output, is 
used to store the resulting linked module. The link editor prints out 
the LINKCNTL file (Appendix A, Figure A-4) and any unresolved 
references resulting from the link edit on the system printer. There 
will be several unresolved weak external references (WXTRN) for 
supervisor support modules you did not want to include, but no 
unresolved EXTRN messages should appear. 

$JOBUTI L now loads $UPDATE to format the linked supervisor into 
a loadable module (Appendix A, bottom of Figure A-4). 
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$JOBUTIL 
(EDX002) 



\\ \ EDX002 




Figure 15-17. $UPDATE 



The formatted load module is placed in $EDXNUCT, a supervisor data 
set allocated automatically by $UPDATE. $UPDATE ends (Appendix 
A, Figure A-5) and $JOBUTI L completes. 
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Designate Tailored Supervisor 



Before you can test the new supervisor, it must be designated as the one 
to be loaded at I PL time. To do this you must invoke $INITDSK and 
write a new I PL text record (command II) designating $EDXNUCT on 
EDX002 as the new supervisor. 

Figure 15-18 summarizes the tailored system generation process. 
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SJOBUTIL 
(EDX002) 



W \ EDX002 




\ 



SUPDATE 
(EDX002) 



SCOPY 
(EDX002) 



Figure 15-18. SYSGEN overview 



XS3002 

• 

o 


SUPERVISOR 
OBJECT 


1 


MODULES 



EDX002 
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IPL Tailored Supervisor 



When you IPL the tailored supervisor, the IPL message shown in 
Figure 15-19 is displayed. 



*** EVENT DRIVEN EXECUTIVE *** VER 3.0 

IPL = $EDXNUCT,EDX002 

STORAGE MAP 
PART= START SIZE 

1 40448 16H96 

2 57344 3276H 

3 90112 40960 

SET DATE AND TIME USING COMMAND ST 
EDX INITIALIZATION COMPLETE 



Figure 15-19. IPL message 



The message on the $SYSLOG device indicates that $EDXNUCT is the 
supervisor that was loaded and that it is 40K bytes in size. Partition 
sizes are as shown. Users may now execute programs under the tailored 
system. 



1 5-26 SR30-0436 



Section 16. Program Preparation Using $EDXASM 



y 



OBJECTIVES: After completing this section, the student should be 
able to; 

1. Describe the steps required for application program preparation 

2. Understand the operation of the online utilities/programs used 
for program preparation (5719-XX2) 

READING ASSIGNMENT: IBM Series/ 1 Event Driven Executive 
System Guide (SC34-1702), "Program Preparation." 



PROGRAM PREPARATION OVERVIEW 



The steps required to prepare an Event Driven Executive application 
program for execution are outlined in Figure 16-1 . 

STEP1: CREATE SOURCE MODULE 

Source program modules are created using either $EDIT1 N or 
$FSEDIT, the text editing utilities. 

STEP 2: ASSEMBLE SOURCE MODULE 

$EDXASM, the assembler program, produces object modules 
from source modules. An object module may be input to the link 
edit program $LINK or, if no references to external modules are 
made, it may be input to the formatting utility $UPDATE. 

STEP 3: PRODUCE ASSEMBLY LISTING 

This is a subfunction of the assembly, STEP 2. The listing can be 
suppressed entirely, or errors only printed. The listing may be 
directed to a device other than the system printer, if desired. The 
listing is produced by $EDXLIST, a separate program loaded by 
$EDXASM as required. 

STEP 4: LINK EDIT OBJECT MODULES 

The $LINK program is used to combine object modules to form a 
complete program. This step is not required if the object module 
produced by an assembly is already a complete program in itself 
(no references to external modules included in the assembly). 

STEP 5: FORMAT OBJECT MODULE 

Program object modules produced by $EDXASM or $LINK are 
not In executable form. They must first be processed into relo- 
catable load modules by the utility program $UPDATE. 
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$EDIT1N 
$FSEDIT 



STEP1: CREATE/MODIFY SOURCE MODULE 



$EDXASM 



STEP 4: LINK EDIT 
OBJECT MODULES 
(IF REQUIRED) 



STEP 2: ASSEMBLE SOURCE 
MODULE (PRODUCE OBJECT 
MODULE) 



$EDXLIST 
(OPTIONAL) 



STEP 3: PRODUCE 
ASSEMBLY LISTING 
(OPTIONAL) 



SLINK 

(AS REQUIRED) 



STEP 5: FORMAT OBJECT MODULE INTO 
RELOCATABLE LOAD MODULE 
(EXECUTABLE PROGRAM) 



SUPDATE 



SJOBUTIL 



RUN STEP 2, STEP 3, STEP 4, AND 
STEP 5 AS BATCH JOB STREAM 



Figure 16-1. Program preparation overview 



$JOBUTIL: BATCH JOB STREAM PROCESSOR 

At the bottom of Figure 16-1 is a reference to $JOBUTIL, the 
batch job stream processor. This is a program preparation produc- 
tivity aid which allows the assembly, link edit, and formatting 
steps to be run as a continuous sequence of job steps, without 
operator intervention. 

In this section, the features and operating characteristics of each of the 
programs/utilities required for program preparation is discussed 
separately. Following the discussion is a comprehensive example, using 
each utility in preparing a program for execution. 
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$EDXASM 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$EDXASM." 

$EDXASM is the system program used for assembly of source pro- 
grams written in the Event Driven Executive language. $EDXASM, 
along with other program preparation programs, resides on volume 
ASMLIB. 

Data Set Requirements. $EDXASM is loaded using the "$L" supervisor 
utility function. The operator will be prompted for required data set 
names, as shown in Figure 16-2. 



> 



$L $EDXASM, ASMLIB 



SOURCE (NAME, VOLUME): 
WORKFILE(NAME, VOLUME): 
OBJECT (NAME, VOLUME): 

Figure 16-2. SEDXASM (1) 



SRCINPUT 



WORKSET 



OBJOUT 



The SOURCE data set is the input source module to be assembled, 
statements in this file are created using $EDIT1N or $FSEDIT. 



The 



For WORKFILE, enter the name of a data set to be used as an 
assembler work area. This file must already be allocated, and usually 
ranges between 100 and 500 records in size, with 250 about average. 

The OBJECT data set is the preallocated data set in which the object 
module resulting from the assembly will be stored. This object module 
will be input either to $LINK, if it is to be combined with other object 
modules, or to $UPDATE, if it is a complete program (no references 
to external modules). 

In Figure 16-2, all three data sets reside on the IPL volume, as no 
volume names are supplied. Were the data sets resident on other 
volumes, each data set name would be followed by the volume, separ- 
ated by a comma. 

The loader ($L function) is a serially reusable resource. In Figure 
16-2, the loader is enqueued, and therefore unavailable to other users 
and to the system, as soon as the ENTER key is pressed to enter the 
first line, $L $EDXASM,ASMLIB. It remains enqueued throughout 
the prompt/response sequence that follows, a length of time which 
may be considerable, depending on how familiar the operator is with 
the data set names requested, and how fast they can be entered. 
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> $L $EDXASM,ASMLIB SRCINPUT WORKSET OBJOUT 



Figure 16-3. $EDXASM (2) 

Figure 16-3 illustrates an alternate way of entering the same load 
request. When the ENTER key is pressed, all required data set names 
are available on the same line, and enqueue time for the loader is 
greatly reduced. For $EDXASM, and all other utilities accepting 
advance input, the advance input form should be used where possible. 
Note: Utilities accepting advance input have no way of "knowing" 
the purpose of a data set, other than by the position of the data set 
name on the advance input line. The data set names must be supplied 
on the advance input line in the same sequence as the utility would 
prompt for them were advance input not employed. 

In addition to source, work, and object data sets, whose names must 
be supplied at load time, $EDXASM also uses a language control data 
set. The language control data set supplied with the system Is called 
$EDXL and contains the assembler error messages and an "op code 
to processing module" specification for each of the standard Event 
Driven Executive instructions. If users wish to modify the Instruction 
set or add error messages, $EDXL may be changed, or a new language 
control data set produced (the language control data set Is in source 
statement format, and can be modified using $EDIT1N or $FSEDIT). 

$EDXASM supports the copycode function, which allows source code 
residing in data sets to be included in an assembly by coding a 
COPY statement in the source program. The language control data 
set is used to define disk or diskette volumes containing copycode 
data sets to the assembler. 

$EDXL, the system-supplied language control data set, already con- 
tains *COPYCOD statements which define disk volumes ASM LIB 
and EDX002 as volumes containing copycode data sets. If a user- 
written copycode data set resides on either of these volumes, no 
change to $EDXL Is required to use the COPY statement in a user 
source program assembly. However, if a user copycode data set 
resides on a volume other than ASMLIB or EDX002, $EDIT1N or 
$FSEDIT must be used to add a *COPYCOD statement to $EDXL 
which defines the new volume as one which may contain copycode 
data sets. 

After $EDXASM has been loaded the SELECT OPTIONS (?): prompt 
will appear. A "1" response will list the available options, as shown in 
Figure 16-4. 

SELECT OPTIONS (?) : [3 

LIST - SPECIFY LIST DEVICE 

NOLIST - DO NOT PRINT LISTING 

ERRORS - LIST ERRORS ONLY 

CONTROL - SPECIFY CONTROL LANGUAGE 

END - END OPTION SELECTION 

('ATTN - CA' TO CANCEL ASSEMBLY) 



Figure 16-4. $EDXASM (3) 
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LIST You can specify the name of the device that will be used 

for the assembly listing (name=label in TERMINAL system 
configuration statement). If the LIST option is not 
entered, the list device will default to $SYSPRTR. 

NO LIST This option suppresses the listing entirely, but assembly 
statistics will be displayed on the loading terminal. 

ERRORS Only statements causing assembly errors, along with their 
error messages, will be listed. The operator will also be 
prompted for the name of the error list device. 

CONTROL You can specify the name of your own language control 
data set. If it is not entered, this option defaults to 
$EDXL on volume ASMLIB. 

END Once any option is entered in response to the SELECT 

OPTIONS (?): prompt, the operator will continue to be 
prompted until END is entered, or until the ENTER key is 
depressed with no entry. If no response is made to the 
first SELECT OPTIONS (?): prompt (ENTER key with 
nothing entered), the assembly will start without END's 
being entered, $EDXL on ASMLIB will be used as the 
language control data set, and the full listing will appear 
on the system printer ($SYSPRTR). 



$EDXLIST 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$EDXLIST." 

The assembly listing is produced by the assembly list processing program 
$EDXLIST. Though usually run as part of the assembly process, 
$EDXLIST may be loaded directly ($L) and run after the assembly is 
finished, as long as the assembler work data set has not been disturbed 
(used in another assembly). See the reading assignment for operating 
instructions. 



$LINK 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$LINK- 
Linkage Editor." 

$LINK is used to combine two or more object modules into a single 
output object module. Input object modules may be produced by 
$EDXASM, by the Series/1 macro assembler ($S1ASM), by the PL/I, 
FORTRAN or COBOL compilers, or by the Host Assembler. The 
output object module produced by $LINK must be processed by 
$UPDATE before it can be loaded and executed. 
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Data Set Requirements. When $LINK is loaded, the operator is 
prompted for the names of three data sets. The first is the link control 
data set, which will contain control records specifying the object 
modules (names of object module data sets) that will be linked together. 
The other two data set names are the names of link edit work data sets, 
used as work areas during the linkedit process. 



> $L $LINK 
LINKCNTL(NAME, VOLUME) 
LEWORKl (NAME, VOLUME) 
LEW0RK2 (NAME, VOLUME) 

SLINK 76P, 00:40 



LINKCNTL 



LINKWRKl 



LINKWRK2 



39, LP= 5F00 



ENTER DEVICE NAME FOR PRINTED OUTPUT 



SSYSPRTR 



Figure 16-5. $LINK (1) 



See the reading assignment for recommended work data set sizes. 

The link control data set (LINKCNTL) controls overall link edit opera- 
tion. The control records are produced using $EDIT1N or $FSEDIT. 
The first control record in all LINKCNTL data sets is an OUTPUT 
statement, specifying the data set that will be used to store the output 
object module resulting from the link edit. This data set (as well as 
the work data sets) must be allocated before the link operation is 
attempted. In Figure 16-6, the output statement specifies data set 
LINKOUT on the IPL volume (if no volume is specified, defauIt=IPL) 
as the output data set for the linked object module. 



c 



OUTPUT LINKOUT 

INCLUDE ASM0UT1,EDX003 

INCLUDE ASM0UT5 
END 

Figure 16-6. SLINK (2) 



The output object module will be produced by linking the input object 
module in ASM0UT1 on volume EDX003 with the object module in 
ASM0UT5 on the IPL volume, as specified by the two INCLUDE 
statements following the OUTPUT record. The first INCLUDE record 
must specify an object module that contains an initial task, produced 
by an assembly of a source module beginning with a PROGRAM state- 
ment with the MAIN= operand coded as (or defaulted to) MAIN=YES. 
Subsequent INCLUDE records cannot specify object modules con- 
taining initial tasks. 

In addition to those object modules explicitly named in INCLUDE 
statements, $LINK can also include object modules through the 
AUTOCALL option. Using the AUTO= operand of the OUTPUT 
control record, an autocall definition data set may be named. This data 
set contains the names (and volumes, if not IPL resident) of autocall 
object modules, along with their entry points. 
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OUTPUT LINKOUT AUT0=MYAUT0,EDX003. 
INCLUDE ASMOUTA 
INCLUDE ASMOUTB 
END 



$JOBUTIL 



RENBR,EDX001 RENUMl RENUM2 

ABTERM ABENT **END 

Figure 16-7. $LINK (3) 



In Figure 1 6-7, a reference to RENUMl, RENUM2, or ABENT from 
within object module ASMOUTA or ASMOUTB cannot be resolved 
by linking ASMOUTA with ASMOUTB. Because AUTO= is coded, 
$LINK goes to the autocall data set MYAUTO, and tries to find the 
referenced name in the list of entry points specified in the autocall 
definition records. If a match is found, $LINK will link the associated 
autocall object module with ASMOUTA and ASMOUTB. 

The **END in the last autocall definition record performs the same 
function for the autocall definition data set as does the END record 
for the link control data set. 

In addition to the link control and work data set names, the operator 
is also prompted for the name (label of TERMINAL system configura- 
tion statement) of the terminal which is to receive the $LINK output 
messages (see Figure 16-5). $LINK prints out the link control state- 
ment file, and a map of the linked object module (see the reading 
assignment for an example). 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference, Messages and Codes (SC34-1703), "$JOBUTI L - 
Job Stream Processor." 

$JOBUTI L is the batch job stream processor utility. $JOBUTI L uses a 
user-created ($EDIT1N, $FSEDIT) job processor procedure file to 
sequentially execute a series of programs. To illustrate basic $JOBUTI L 
operation, a procedure file to invoke the online assembler, $EDXASM 
will be created. 

Procedure command statements are stored two statements per record, 
so a data set size of 15 or 20 records is usually adequate. For this dis- 
cussion, assume a data set called MYPROC is allocated on the IPL 
volume. 

Using $EDIT1 N or $FSEDIT, the procedure command file can now be 
created. An asterisk in column 1 defines an internal comment command. 



* $JOBUTIL / $EDXASM EXAMPLE 

Figure 16-8. $JOBUTIL (1) 
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The entire statement is treated as a comment, and may appear anywhere 
within the procedure command file. The internal comment statements 
are for procedure file documentation only; they are not printed out or 
displayed during $JOBUTIL operation. 

All the other procedure commands have a defined positional format. 
The commands must appear in character positions 1 through 8, starting 
in 1; operands in 10 through 17, starting in 10; and comments in 18 
through 71. 

J 

* $JOBUTIL / $EDXASM EXAMPLE 

* 'LOG' COMMAND - $JOBUTIL LOG DEFINITION 
LOG ON 

Figure 16-9. $JOBUTIL (2) 



The LOG command controls the printing of $JOBUTIL procedure com- 
mands, with LOG coded as shown in Figure 16-9, procedure com- 
mands will be displayed on the terminal used to load $JOBUTI L, as 
they are read from the procedure file. Other operand options are either 
OFF, for no logging of procedure commands, or terminal name specify- 
ing the name of a terminal to which you wish the $JOBUTI L procedure 
commands directed. 



* $JOBUTIL / $EDXASM EXAMPLE 

* 'LOG' COMMAND - $JOBUTIL LOG DEFINITION 
LOG ON 

* 'REMARK' COMMAND - DISPLAYS MESSAGE 

* ON LOADING TERMINAL 
REMARK OPERATOR MESSAGE 

\ 

Figure 16-10. $JOBUTIL (3) 



The REMARK command will display on the terminal used to load 
$JOBUTIL. REMARK commands may be placed anywhere within a 
procedure file. The JOB command, like the REMARK command, is 
optional. In Figure 16-11, the JOB command is the first command in 
the procedure data set, but could follow the LOG or the REMARK. 
The JOB command displays a "job started" message on the loading 
terminal, with the time and date. Both JOB and REMARK operate 
without regard to LOG (LOG OFF has no effect). 
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JOB ASMPLE 

* $JOBUTIL / $EDXASM EXAMPLE 

* 'LOG' COMMAND - $JOBUTIL LOG DEFINITION 
LOG ON 

* 'REMARK' COMMAND - DISPLAYS MESSAGE 

* ON LOADING TERMINAL 
REMARK OPERATOR MESSAGE 

* 'PROGRAM' COMMAND DEFINES THE PROGRAM 

* TO BE LOADED 
PROGRAM $EDXASM,ASMLIB 



Figure 16-11. $JOBUTIL (4) 



The PROGRAM command defines the program name/volume that 
$JOBUTI L is to load (if the JOB command is used, it must appear 
before PROGRAM). 



JOB ASMPLE 

* $JOBUTIL / $EDXASM EXAMPLE 

* 'LOG' COMMAND - $JOBUTIL LOG DEFINITION 
LOG ON 

* 'REMARK' COMMAND - DISPLAYS MESSAGE 

* ON LOADING TERMINAL 
REMARK OPERATOR MESSAGE 

* 'PROGRAM' COMMAND DEFINES THE PROGRAM 

* TO BE LOADED 
PROGRAM $EDXASM,ASMLIB 

* 'DS' COMMANDS DEFINE DATA SETS THE 

* LOADED PROGRAM REQUIRES 
DS SCRMAT 

DS ASMWORK 
DS ASM0UT2 



Figure 16-12. $JOBUTIL (5) 



"DS" commands define data sets to the program being loaded. Only 
one data set may be defined with each DS statement, and the defini- 
tions must appear in the same order as the responses to load-time data 
set definition prompts would be entered, were the program loaded 
using the "$L" operator command. 

Following the DS commands, any additional information required by 
the program being loaded is passed using the FARM command. In 
Figure 16-13, FARM is coded with no operand. This is equivalent to 
responding to the SELECT OPTIONS: prompt by pressing the ENTER 
key without entering an option, when $EDXASM is loaded using $L. 
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JOB ASMPLE 

* $JOBUTIL / $EDXASM EXAMPLE 

* 'LOG' COMMAND - $JOBUTIL LOG DEFINITION 
LOG ON 

* 'REMARK' COMMAND - DISPLAYS MESSAGE 

* ON LOADING TERMINAL 
REMARK OPERATOR MESSAGE 

* 'PROGRAM' COMMAND DEFINES THE PROGRAM 

* TO BE LOADED 
PROGRAM $EDXASM,ASMLIB 

* 'DS' COMMANDS DEFINE DATA SETS THE 

* LOADED PROGRAM REQUIRES 
DS SCRMAT 

DS ASMWORK 
DS ASM0UT2 

* 'PARM' COMMAND PASSES PARAMETERS TO 

* THE LOADED PROGRAM 
PARM 



Figure 16-13. $JOBUTIL (6) 

The program to be loaded now has all the information required to load 
and execute. In Figure 16-14, the "EXEC" command issues the load 
request for the program defined in the preceding PROGRAM command. 

JOB ASMPLE 

* $JOBUTIL / $EDXASM EXAMPLE 

* 'LOG' COMMAND - $JOBUTIL LOG DEFINITION 
LOG ON 

* 'REMARK' COMMAND - DISPLAYS MESSAGE 

* ON LOADING TERMINAL 
REMARK OPERATOR MESSAGE 

* 'PROGRAM' COMMAND DEFINES THE PROGRAM 

* TO BE LOADED 
PROGRAM $EDXASM,ASMLIB 

* 'DS' COMMANDS DEFINE DATA SETS THE 

* LOADED PROGRAM REQUIRES 
DS SCRMAT 

DS ASMWORK 
DS ASM0UT2 

* 'PARM' COMMAND PASSES PARAMETERS TO 

* THE LOADED PROGRAM 
PARM 

* 'EXEC COMMAND ISSUES LOAD REQUEST FOR 

* THE PROGRAM 
EXEC 

* 'EOJ' ENDS THE PROCEDURE COMMAND FILE 
EOJ 

Figure 16-14. $JOBUTIL (7) 



16-10 SR30-0436 



The "EOJ" command following the EXEC indicates end of job, and 
terminates the job stream processor utility. If another job were to be 
run before ending this procedure, appropriate PROGRAM, DS, PARM 
and EXEC statements would precede the EOJ. 

When the text editing session that created the procedure is complete, 
the procedure is stored in the data set MYPROC. The job can be run 
by loading $JOBUTI L, and specifying procedure file MYPROC, as 
shown in Figure 16-15. 



> 



$L SJOBUTIL 



$JOBUTIL 3P, 00:00:17, LP= 5F00 

ENTER PROCEDURE (NAME, VOLUME) : IMYPRQC 



Figure 16-15. SJOBUTIL (8) 



In Figure 16-16, each of the procedure command statements in pro- 
cedure file MYPROC (without the internal comments) is related to the 
equivalent operator responses for a $L load of the assembler. 




$Ll l$EDXASM,ASMLIB 



ASM0UT2 



SOURCE (NAME, VOLUME): SCRMAT 
WORKFILE(NAME, VOLUME): 
OBJECT (NAME, VOLUME): 
SEDXASM 76P, 00:46:58 

§ELECT OPTIONS (?): 

Figure 16-16. SJOBUTIL (9) 



JOB 

LOG 

REMARK 
-^PROGRAM 
-*-DS 




ASMPLE 

ON 

OPERATOR MESSAGE 

$EDXASM,ASMLIB 

SCRMAT 

ASMWORK 

ASM0UT2 



Other $JOBUTI L commands allow job steps to be skipped/executed 
based on the completion code returned from a previous step, the 
invoking of nested procedures in other procedure data sets, and the 
entering of procedure commands from the loading terminal. For a 
comprehensive example of $JOBUTI L capabilities, see the Program 
Preparation Example topic that follows. 
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PROGRAM PREPARATION EXAMPLE 



PROBLEM DESCRIPTION 



In the remainder of this section, a source module will be assembled, 
link edited, and formatted. Each step will first be treated separately, 
and then all steps will be combined under control of the batch job 
stream processor utility $JOBUTIL. 



In "Section 11. Terminal I/O", a program was developed, which, using 
a series of PRINTEXT instructions, formatted a data entry screen (see 
the topic Static Screen Coding Example in Section 11). In "Section 
14. Utility Programs," the $IMAGE screen formatting utility was used 
to create the same screen, and to save it in a screen image data set 
named VIDE01. 

Supplied with the Event Driven Executive system are a group of super- 
visor subroutines which allow user programs to access stored screen 
images produced by $IMAGE. The goal of this exercise is to replace 
the user-written formatting instructions (PRINTEXTs) in the program 
developed in Section 1 1 , with the appropriate subroutine calls to access 
the stored screen image in data set VI DE0 1. 
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Create/Modify Source Module 



SEDITIN 
$FSEDIT 



STEP1: CREATE/MODIFY SOURCE MODULE 



SEDXASM 



.STEP 4; LINK EDIT 
OBJECT MODULES 
(IF REQUIRED) 



STEP 2: ASSEMBLE SOURCE 
MODULE (PRODUCE OBJECT 
MODULE) 



$EDXLIST 
(OPTIONAL) 



STEPS: PRODUCE 
ASSEMBLY LISTING 
(OPTIONAL) 



SLINK 

(AS REQUIRED) 



[ STEP 5: FORMAT OBJECT MODULE INTO 

RELOCATABLE LOAD MODULE 
[ (EXECUTABLE PROGRAM) 



SUPDATE 






SJOBUTIL 



RUN STEP 2, STEP 3, STEP 4, AND 
STEP 5 AS BATCH JOB STREAM 



Figure 16-17. Step 1: Create source module 



Data Set Requirements. 



UTILITY 


INPUT 


OUTPUT 


WORK 




SFSEDIT 


CONTROL 




DATA 


DATA 


DATA 


DATA 


VOLUME 


SET 


SET 


SET 


SET 


EDX002 




STATS RC 


EDITWORK 




ASM VOL 


SOURCE 








Figure 16-18. 


Data set requirements (1) 







The source module to be modified is SOURCE on volume ASM VOL. 
Using $FSEDIT, the program is read into the text edit work data set 
(Figure 16-19). 
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Figure 16-19. Program preparation (1) 

The screen formatting code begins at statement 140. in Figure 16-20, 
DD is entered to the left of statement 140, defining the start of a 
bloci< delete. 




Figure 16-20. Program preparation (2) 



Scrolling down through the work area, the end of the formatting code 
is statement 370 where DD defines end of block delete. 
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EDIT -- EDIIWORK, EDX002 
COMMAND INPUT =^-=-> 



00220 
00230 
00240 
00250 HDR 
00260 
00270 
00280 
00290 
00300 Al 
00310 
00320 A2 
00330 
00340 
00350 
00360 
lDg0O37O 

00380 WAITONE 
00390 
00400 El 
00410 
00420 E2 
00430 



PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

MOVE 

DO 

PRINTEXT 

PRINTEXT 

ADD 

PRINTEXT 

ADD 

PRINTEXT 

ADD 

ENDDO 

PRINTEXT 

TERMCTRL 

WAIT 

GOTO 

MOVE 

GOTO 

MOVE 

GOTO 



75 { 543)- 



BLOCK COMMAND INCOMPLETE 



SCROLL 



DASHES, PR0TECT=YES,LINE=3 

'CLASS NAME:',LINE=4.PR0TECT=YES 

'INSTRUCTOR NAME: ' ,LINE=4,PR0TECT=YES,SPACES=32 

DASHES, PR0TECT=YES,LINE=5 

LINENBR,6 

4, TIMES 

'NAME: ' ,LINE=LINENBR,PROTECT=YES 

'STREET: ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 

LINENBR.l 

'CITY : ' ,LINE=LINENBR,SPACES=30,PR0TECT=YES 

LINENBR.l 

'STATE : ' ,LINE=LINENBR,SPACES=30,PROTECT=YES 

LINENBR,3 

LINE=4,SPACES=1I 

DISPLAY 

KEY 

(READ,El,E2,E3,E4),XMPLSTAT+2 

LINENBR,6 

DELETE 

LINEMBR.ll 

DELETE 



'HALF 



Figure 16-21. Program preparation (3) 

After ENTER has been pressed and after you have scrolled back to the 
top of the data set, you will see the screen in Figure 16-22 with state- 
ments 140 through 370 deleted. 



EDIT -- EDITMORK, EDX002 
COMMAND INPUT =-=> 



51( S43) COLUMNS 001 072 

SCROLL ==->HALF 



***** 


***** TOP OF DATA 


******************************************* 


00010 


XMPLSTAT 


PROGRAM 


START 


00020 


lOCBl 


lOCB 


NHIST=0 


00030 


I0CB2 


lOCB 


SCREEN=STATIC 


00040 




ATTN LI ST 


(END, OUT, SPF, STATIC) 


00050 


START 


ENQT 


lOCBl 


00060 




PRINTEXT 


'CLASS ROSTER PROGRAM' ,SPACES-15,LINE=1 


00070 




PRINTEXT 


'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 


00080 




PRINTEXT 


' THE PROGRAM' 


00090 




PRINTEXT 


'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 


00100 




PRINTEXT 


' BRING UP THE ENTRY SCREEN' 


00110 




DEQT 




00120 


CHECK 


WAIT 


ATTNECB. RESET 


00130. 




IF 


(ATTNECB,EQ.1),G0T0,ENDIT 


00380 


WAITONE 


WAIT 


KEY 


00390 




GOTO 


(READ,E1,E2,E3,E4) ,XMPLSTAT+2 


00400 


El 


MOVE 


LINENBR,6 


00410 




GOTO 


DELETE 


00420 


E2 


MOVE 


LINENBR.ll 


00430 




GOTO 


DELETE 


00440 


E3 


MOVE 


LINENBR,16 


00450 




GOTO . 


DELETE 





Figure 16-22. Program preparation (4) 

By using the Insert function of EDIT mode, the statements required to 
access the screen image in data set VI DE0 1 can now be added. 
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$IMOPEN 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
System Guide (SC34-0312), "Formatted Screen Images." 

The first step in using a stored screen image is to read the image data 
set into the user program. 



\ 

IMAGEBUF BUFFER 
DSETNAME TEXT 

\ 

GETIMAGE CALL 



758, BYTES 
'VIDE01,EDX002' 

$IMOPEN, (DSETNAME), (IMAGEBUF) 



Figure 16-23. Program preparation (5) 



Using subroutine $IMOPEN, the data set is read into a user buffer. The 
name of the data set is specified in a TEXT statement, and the label of 
the TEXT statement is passed to $IMOPEN as the first parameter in the 
CALL. The second parameter is the label of the buffer which will 
receive the image. Both parameters must be enclosed in parentheses. 

The buffer is defined by a BUFFER statement, in bytes. Data set 
VIDE01 is three records in length, so IMAGEBUF is defined as 768 
bytes. 

$IMOPEN returns a completion code in "taskname+2", and it is a 
user responsibility to check for proper completion (-1 completion 
code). In Figure 16-24, the completion code check and error routine 
have been added. 



IMAGEBUF BUFFER 
DSETNAME TEXT 



768, BYTES 
'VIDE01,EDX002 



GETIMAGE CALL $IMOPEN, (DSETNAME) , (IMAGEBUF) 

IF (XMPLSTAT+2,NE,-1) 

MOVE ERRC0DE,XMPLSTAT+2 

PRINTEXT '@IMAGE OPEN ERROR, CODE =' 

PRINTNUM ERRCODE 

GOTO ERRQUERY 
ENDIF 



ERRCODE DATA F'O' 

ERRQUERY QUESTION '(BRETRY OPEN ? ' ,YES=GETIMAGE,NO=ENDIT 



Figure 16-24. Program preparation (6) 
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$IMDEFN 



Before the screen can be displayed, the terminal must be enqueued as a 
static screen device. In Figure 16-25, the ENQT I0CB2 is preceded by 
a CALL to subroutine $IMDEFN. This subroutine fills in the user-coded 
lOCB with the screen dimensions of the screen image in the buffer. 
The CALL to $IMDEFN is not a required function; the lOCB may be 
enqueued without first calling the subroutine. By calling $IMDEFN, 
you are assured that the lOCB will have the proper screen dimensions 
for the screen in the buffer. If $IMAGE is used to change the dimen- 
sions of the stored screen image, the new dimensions will be placed in 
the lOCB by $IMDEFN when the program next accesses that screen, 
with no change in the user program code required. 



IMAGEBUF BUFFER 768, BYTES 

DSETNAME TEXT ' VIDEOl ,EDX002 



I0CB2 lOCB 



SCREEN=STATIC 



GETIMAGE CALL $IMOPEN, (DSETNAME) , (IMAGEBUF) 
IF (XMPLSTAT+2,NE,-1) 
MOVE ERRC0DE,XMPLSTAT+2 
PRINTEXT '@IMAGE OPEN ERROR, CODE =' 
PRINTNUM ERRCODE 
ERRQUERY 



GOTO 
ENDIF 
CALL 
ENQT 



$IMDEFN,(I0CB2), (IMAGEBUF) 
I0CB2 



$IMPROT/$IMDATA 



ERRCODE DATA F'O' 

ERRQUERY QUESTION '@RETRY OPEN ? ' ,YES=GETIMAGE,NO=ENDIT 

Figure 16-25. Program preparation (7) 



Now that the terminal is enqueued, the screen image in the buffer can 
be displayed. In Figure 16-26, the TERMCTRL BLANK following 
the ENQT blanks the screen, preventing flicker while the image is 
written. The CALL of subroutine $IMPROT transfers all the protected 
data from the image buffer to the screen, and the call to $IMDATA 
transfers the unprotected data. (If a screen image consists of all pro- 
tected or all unprotected data, only the appropriate subroutine need 
be called.) 
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IMAGEBUF BUFFER 768, BYTES 
DSETNAME TEXT ' VIDEOl ,EDX002 



I0CB2 


lOCB 


SCREEN=STATIC. 


GETIMAGE 


CALL 


$IMOPEN, (DSETNAME) , ( IMAGEBUF) 




IF 


(XMPLSTAT+2,NE,-1) 




MOVE 


ERRC0DE,XMPLSTAT+2 




PRINTEXT 


'@IMAGE OPEN ERROR, CODE =' 




PRINTNUM 


ERRCODE 




GOTO 


ERRQUERY 




ENDIF 






CALL 


$IMDEFN,(I0CB2), (IMAGEBUF) 




ENQT 


I0CB2 




TERMCTRL 


BLANK 




CALL 


$IMPROT,( IMAGEBUF), 




CALL 


$IMDATA,( IMAGEBUF) 




PRINTEXT 


LINE=4,SPACES=11 



TERMCTRL DISPLAY 



ERRCODE DATA 
ERRQUERY QUESTION 



F'O' 

'(BRETRY OPEN ? 



,YES=GETIMAGE,NO=ENDIT 



Figure 16-26, Program preparation (8) 



The PRINTEXT following the last CALL positions the cursor at the 
first data entry field, and TERMCTR L DISPLAY unblanks the 
screen. 

The second parameter of the CALL $IMPROT statement (Figure 16-26) 
is coded as 0. This could be coded as the label of a BUFFER statement, 
in which case the $IMPROT subroutine will build a table of the location 
and sizes of all unprotected (data entry) fields on the screen. Each table 
entry is three words in length. The first word will contain the line 
number and the second, the starting position of the field within the 
line (spaces from left margin of screen). The third word will contain 
the length of the field. These entries can be used to read/write data 
entry fields on the screen. 
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C^ The "$IM" subroutines are supplied as object modules. Because they 

) are object modules, they are combined with the user program in the link 

edit step, not during assembly. They must therefore be declared as 
external references in an EXTRN statement. 

Figures 1 6-27 and 1 6-28 are listings of the edit work data set after the 
edit session is complete. The EXTRN statement is statement 20, with 
the image buffer and screen image data set name definition following 
at 30 and 40. Other added statements include the "$IM" code from 
170 to 300, and the two statements at 670 and 680. The source 
module modification is complete. The work data set is written to 
STATSRC on volume EDX002 ($FSEDIT Primary Option 4), complet- 
ing Step 1 of the program preparation process. 
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00010 

00020 

00030 

00040 

00050 

00060 

00070 

00080 

00090 

00100 

00110 

00120 

00130 

00140 

00150 

00160 

00170 

00180 

00190 

00200 

00210 

00220 

00230 

00240 

00250 

00260 

00270 

00280 

00290 

00300 

00310 

00320 

00330 

00340 

00350 

00360 

00370 

00380 

00390 

00400 

00410 

00420: 

00430 

00440 

00450 

00460 

00470 

00480 

00490 



XMPLSTAT 

IMAGEBUF 
DSETNAME 
lOCBl 
I0CB2 

START 



CHECK 
GETIMAGE 



WAITONE 

El 

E2 

E3 

E4 
DELETE 



READ 



PROGRAM 

EXTRN 

BUFFER 

TEXT 

lOCB 

lOCB 

ATTN LI ST 

ENQT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

PRINTEXT 

DEQT 

WAIT 

IF 

CALL 

IF 

MOVE 

PRINTEXT 

PRINTNUM 

GOTO 
ENDIF 
CALL 
ENQT 

TERMCTRL 
CALL 
CALL 

PRINTEXT 
TERMCTRL 
WAIT 
GOTO 
MOVE 
GOTO 
MOVE 
GOTO 
MOVE 
GOTO 
MOVE 
ERASE 
ADD 
..ERASE 
ADD 
ERASE 
SUBTRACT 
PRINTEXT 
TERMCTRL 
GOTO 
QUESTION 



START 

$IMOPEN,$IMDEFN,$IMPROT,$IMDATA 

768, BYTES 

'VIDE01,EDX002' 

NHIST=0 

SCREEN=STATIC 

(END, OUT, $PF, STATIC) 

lOCBl 

CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 
HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

THE PROGRAM' 
HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 
BRING UP THE ENTRY SCREEN' 

ATTNECB, RESET 
(ATTNECB,EQ,1),G0T0,ENDIT 
$IMOPEN,( DSETNAME), (IMAGEBUF) 
(XMPLSTAT+2,NE,-1) 

ERRC0DE,XMPLSTAT+2 

'(aiMAGE OPEN ERROR, CODE =' 

ERRCODE 

ERRQUERY 

$IMDEFN,(I0CB2), (IMAGEBUF) 

I0CB2 

BLANK 

$IMPROT, (IMAGEBUF), 

$IMDATA,( IMAGEBUF) 

LINE=4,SPACES=11 

DISPLAY 

KEY 

(READ,El,E2,E3,E4),XMPLSTAT+2 

LINENBR,6 

DELETE 

LINENBR,11 

DELETE 

LINENBR,16 

DELETE 

LINENBR,21 

MODE=LINE,TYPE=DATA,LINE=LINENBR 

LINENBR,1 

MODE=LINE,TYPE=DATA,LINE=LINENBR 

LINENBR,1 

MODE=LINE,TYPE=DATA,LINE=LINENR 

LINENBR,2 

LINE=LINENBR,SPACES=5 

DISPLAY 

WAITONE 

'MORE ENTRIES ? ' ,LINE=2,SPACES=55,N0=CLEANUP 



Figure 16-27. Program preparation (10) 
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00500 




ERASE 


M0DE=LINE,LINE=2,SPACES=55,TYPE=DATA 


00510 




ERASE 


M0DE=SCREEN,LINE=6 


00520 




PRINTEXT 


LINE=6,SPACES=5 


00530 




TERMCTRL 


DISPLAY 


00540 




GOTO 


WAITONE 


00550 


CLEANUP 


ERASE 


MODE=SCREEN,TYPE=ALL 


00560 




DEQT 




00570 




GOTO START 




00580 


ENDIT 


PROGSTOP 




00590 




DATA 


X'5050' 


00600 


DASHES 


DATA 


80C'-' 


00610 


OUT 


POST 


ATTNECB, 1 


00620 




ENDATTN 




00630 


STATIC 


POST 


ATTNECB, -1 


00640 




ENDATTN 




00650 


ATTNECB 


ECB 




00660 


LINENBR 


DATA 


F'O' 


00670 


ERRCODE 


DATA 


F'O' 


00680 


ERRQUERY 


QUESTION 


'gRETRY OPEN ? ' ,YES=GETIMAGE ,N0=END 


00690 




ENDPROG 




00700 




END 





Figure 16-28. Program preparation (10 continued) 




Figure 16-29. Program preparation (11) 
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Assemble Source Module 



Data Set Requirements 



■^^. ,iH»,>-y;< B pH<pw K^^ i 1 iji u I y « ^;!y^ 






SEOITIN 
SFSEDtT 



STEP 1 : CREATE/MODIPY SOUfiCf U&Om^l 






SEDXASM 



STEP 4: LINK EDIT 
OBJECT MODULES 
jIF REQUIRED) 



STEP 2: ASSEMBLE SOURCE 
MODULE (PRODUCE OBJECT 
MODULE) 



SfeDXLtST 
lOPTIOHAU 



STEPS: PRODUCE 
- MSEMBLY LISTING 
-■ {OPTIONAL} 



$yNK 

, JA$ REQUIRED) 



STEPS: FORMAT OBJECT MODULE INTO' 
RELOCATABLE LOAD MODULE • 
(EXECUTABLE PROGRAM) 



$UPDATE 







RUN STEP 2, STEP 3, STBP 4, AMp 
STEP 5 AS BATCH JOB STBEAM • ''' 



Figure 16-30. Step 2: Assemble source module 



UTILITY 





INPUT 


OUTPUT 


WORK 


CONTROL 


SEDXASM 


DATA 


DATA 


DATA 


DATA 




SET 


SET 


SET 


SET 


VOLUME 










EDX002 


STATS RC 


ASMOUT 


ASMWORK 




ASM LIB 








$EDXL 


ASMVOL 











Figure 16-31 . Data set requirements (12) 
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In Figure 16-32, the load request for the assembler is entered. Since 
the prompting sequence for the data set required by the assembler is 
known, these data set names are entered as advance input on the 
same line as the input request. 



> $L $EDXASM,ASMLIB STATSRC ASMWORK ASMQUT 



$EDXASM 76P, 03:14:35, LP= 7F00 



SELECT OPTIONS (?): [END 



Figure 16-32. Program preparation (12) 

Because no options are selected, a full listing will be produced on the 
system printer, and the language control data set used for this 
assembly will be $EDXL. When the assembler finishes, the resulting 
object module will be stored in ASMOUT on volume EDX002. 
$EDXASM will then load $EDXLIST to produce the assembly listing. 
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Produce Assembly Listing 



Data Set Requirements 



$E0IT1N 
SFSEDIT 






STEP V. CREATE/MODIFY SOURCE MODULE 






SEDXASM 



I 

\ STEP 4: LINK EDIT 
OBJECT MODULES 
I (IF REQUIRED) 



STEP 2: ASSEMBLE SOURCE 
MODULE (PRODUCE OBJECT 
MODULE) 



SEDXLIST 
(OPTIONAL) 



STEP 3: PRODUCE 
ASSEMBLY LISTING 
(OPTIONAL) 



SLINK 

(AS REQUIRED) 



STEP 5: FORMAT OBJECTMODULE INTO 
RELOCATABLE LOAD MODULE 
(EXECUTABLE PROGRAM) 



SJOBUTIL 



RUN STEP 2, STEP 3, STEP 4, AND 
STEP 5 AS BATCH JOB STREAM 



Figure 16-33. Step 3: Produce assembly listing 



'-supoate: :.\; 



UTILITY 










SEDXLIST 






INPUT 


OUTPUT 


WORK 


CONTROL 




DATA 


DATA 


DATA 


DATA 


VOLUME 


SET 


SET 


SET 


SET 


EDX002 


ASMWORK 
STATS RC 








ASMLIB 








$EDXL 


Figure 16-34. 


Data set requirements (3) 
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In this example, $EDXLIST is loaded by $EDXASM. If the response 
to the SELECT OPTIONS (?): prompt had been NOLIST, $EDXLIST 
would not have been invoked by $EDXASM, but can still be loaded as 
a separate program by the operator. For example, if NOLIST were 
selected, and the assembly statistics displayed on the loading terminal 
at the end of the assembly indicated that there were assembly errors, 
$EDXLIST can then be loaded to print a listing. $EDXLIST will 
prompt for the source data set and the assembler work data set, and 
will get the name of the language control data set from the work data 
set, in which it is stored, at the end of the assembly. As long as an 
intervening assembly has not altered the contents of the assembler 
work data set, and you have not modified the source or language 
control data sets, $EDXLIST will produce the same listing when loaded 
by the terminal operator after an assembly as it would were it loaded 
by $EDXASM as part of the assembly step. 

The assembly listing produced by the assembly requested in Figure 
16-32 is shown in Appendix B, Figure B-1. 



Link Edit Object Modules 



$EDIT1N 
SFSRDIT 



STEP 1; CREATE/MODIFY SOURCE MODULE 



SEDXASM 



STEP 4: LINK EDIT 
OBJECT MODULES 
(IF REQUIRED) 



FO- 



STER 2: ASSEMBLE SOURCE 
MODULE (PRODUCE OBJECT 
MODULE) 



■T 



SEDXLIST 
(OPTIOWAL) 



STEP 3: PRODUCE 
ASSEMBLY LISTING 
(OPTIONAL) 



SLINK 

(AS REQUIRED) 



STEPS: FORMAT OBJECT MODULE INTO 
RELOCATABLE LOAD MODULE 
(EXECUTABLE PROGRAM) 



SUPDATE 



SJOBUTIL 



RUN STEP 2. STEP 3, STEP 4, AND 
STEP 5 AS BATCH JOB STREAM 



Figure 16-35. Step 4: Link edit object modules 
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Data Set Requirements 



lUTILITYl 










SLINK 


INPUT 


OUTPUT 


WORK 


CONTROL 




DATA 


DATA 


DATA 


DATA 


VOLUME 


SET 


SET 


SET 


SET 



EDX002 ASMOUT LINKOUT 

ASMLIB $AUTO 

$LEMSG 
$IMGEN 
SIMOPEN 



LINKWRK1 
LINKWRK2 



LINKSTAT 



Figure 16-36. Data set requirements (4) 

The screen formatting subroutines {$IMOPEN, $IMDEFN, $IMDATA, 
$IMPROT) used by tiie source program are distributed in the form of 
object modules. To include these subroutines in the program, the 
object module output of the assembly (data set ASMOUT) must be 
linked with the screen formatting support object modules. 

Instead of requiring that INCLUDE control records for the screen 
formatting object modules be user-defined, they are system-defined in 
the system-supplied autocall data set $AUTO, and may be included 
using the autocall option. 



00010 


tGPLIST,AS^^LIB 


SGPLIST 




00020 


IPUHCtASMLI J 


$P!mc 




000 30 


tGEPM,ASMLlD 


SGEPM 




00040 


SGEAC, ASMLIB 


$GEAC 




00050 


tSCIM, ASMLIB 


$$GIN 




00060 


IPUF-CfASMLIn 


tPUFC 




00070 


tPUXCASMLI'^ 


$PUXC 




00030 


$GE&t?,ASMLir5 


SGEER 




00090 


SGGXCASMLIii 


IGEXC 




ooioo 


$$SLff£ENtASMLI8 


ttSCRF^N 




03110 


tPUIC»ASWLIF\ 


$PUIC 




00120 


$PUSC,A1,MLI-* 


$PUSC 




00130 


f.GESC, ASMLIB 


SGESC 




00140 


$GEFCfASMLI? 


SGFFC 




001 'jC 


$PUAC,A5^LI? 


iPUAC 




00160 


IPUtCASMLI;-. 


IPUEC 




00170 


$Grir,ASMLI^^ 


$G^;IC 




001 JO 


S$PGI.N»ASMLIS 


$ SPG IN 




0)190 


^SC'J^iCAT, ASMLIB 


SSCONCAT 




00200 


S'bXYPLCiTtASVLIP 


i$XYPLOT 




0O210 


$MFSL,ASMLIt^ 


iMFSL 




Oi)?20 


$I'^:FN, ASMLI? 


ilMOEFvi SIMPKOT 


SI '.OATA 


0J2 30 


$PACK,ASMLI-J 


IPACK 




0J?40 


SUNPACK, ASMLIB 


i UN PACK 




00?bO 


SIvoPEMfAS^LIi^ 


ilMOPEN OSUPfcN 




00260 


$5R.ETURN»ASML1B 


KcTURM 




002 70 


tSSVCtASMLIB 


SVC 




0023 


$I"OTYPEf ASMLIB 


ilMDTYPF 




00 2 90 


SEOXATSRtASMLIB 


SETCUSY SUPFXIT 


*«cNO 



Figure 16-37. Program preparation (13) 
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Figure 16-37 is a listing of $AUTO, the system-supplied autocall data 
set. The screen formatting support modules are specified in autocall 
definition statements 220 and 250. 

If you wished to have your own autocall definitions, you could add 
them to this data set, and continue to use the system-supplied autocall 
data set $AUTO, or build your own autocall data set. In either case, 
the last statement in the data set must contain the "**END" text, 
indicating the end of the autocall data set. 

The output object module data set, the autocall data set (if required), 
and the object modules to be linked are passed to the link editor in the 
link control data set. The link control data set used for this example 
is named LINKSTAT. In Figure 16-38, the link control statements 
required for this link edit are listed, along with some preceding comment 
lines explaining their function. 

00010 * THIS LINK EDIT CONTROL DATA SET SPECIFIES: 
00020 * 1) THE LINKED OUTPUT OBJECT MODULE WILL 

00030 * BE STORED IN 'LINKOUT' ON EDX002 

00040 * 2) THE AUTOCALL DATA SET IS '$AUTO' ON 

00050 * VOLUME ASMLIB (SYSTEM SUPPLIED) 

00060 * 3) 'ASMOUT' ON EDX002 IS THE ONLY INPUT 

00070 * OBJECT MODULE TO BE INCLUDED 

00080 * 

00090 OUTPUT LINKOUT AUT0=$AUT0, ASMLIB 
00100 INCLUDE ASMOUT 
00110 END 

Figure 16-38. Program preparation (14) 



This control statement file is created using $EDIT1N or $FSEDIT, and 
stored in LINKSTAT using the SAVE/WRITE function at the end of 
the text edit session. 



> $L $LINK,EDX002 LINKSTAT LINKWRKl LINKWRK2 



$LINK 76P, 03:31:45, LP= 7F00 

ENTER DEV ICE NAME FOR PRINTED OUTPUT 
($SYSPRTR \ 

Figure 16-39. Program preparation (15) 
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At $LINK load time, the operator supplies the name of the link control 
data set and the two link edit work data sets, along with the name of 
the device to which link editor messages will be directed.^ The link 
editor, using the LINKSTAT link control data set, links the assembled 
object module in ASMOUT (INCLUDE control statement) with screen 
formatting object modules in ASM LIB, found through autocall defini- 
tions In $AUTO; the linked object module is stored in LINKOUT 
(OUTPUT control statement). Required error or information messages 
are read from the system-supplied link message data set, $LEMSG. 

See Appendix B, Figure B-2 for the $SYSPRTR output resulting from 
this link edit. 



Format Object Module 



SEOmN 
SFSEDIl 



STEP 1. CF-(EATE/V.OD)i Y SOURCt I'^inDULe 



STEP 2- ASSfeMBLESOURCb 
MO(JUl.t (PRODUCE OBJE-'CT 
MODULt) 




SEDXl 1ST 
(OPTIONAL) 



STEP 3: PRODUCE 
ASSt'MDLV LIST'MG 
(OPTIONAL) 



STEP 4, LINK briT 
OBJ! CT MOi'^lJLf:^ 

or '^r'v,:!.<f 01 



$LINK 

{AS REQUIRED) 



STEP 5: FORMAT OBJECT MODULE INTO 
RELOCATABLE LOAD MODULE 
(EXECUTABLE PROGRAM) 



SUPDATE 



SJOSUIIL 



-%U-M STPr J!. STcP 3. STEP i. AND 
SI F:P 5 AS BATCH JOB STREAM 



Figure 16-40. Step 5: Format object module 



16-28 SR30-0436 



Data Set Requirements 



UTILITY 



$UPDATE 



VOLUME 



INPUT 


OUTPUT 


WORK 


CONTROL 


DATA 


DATA 


DATA 


DATA 


SET 


SET 


SET 


SET 



EDX002 LINKOUT STATPROG 

Figure 16-41. Data set requirements (5) 

Before a linked (or assembled) object module can be executed, it must 
first be processed by $UPDATE. This utility formats the object 
module into a relocatable load module, acceptable to the system loader. 



> |$L $UPDATE 

SUPDATE 33P, 03:33:10, LP= 7F00 

THE DEFINED INPUT VOLUME IS EDX002, OK? 
THE DEFINED OUTPUT VOLUME IS EDX002, OK? 



COMMAND (?): IRP LINKOUT STATPROG 



Figure 16-42. Program preparation (16) 

The "RP" command means "Read Program", and is followed by the 
name of the object module to be formatted, and the name of the 
resulting executable program. If data set STATPROG is not already 
allocated, $UPDATE will create it. The program STATPROG can be 
loaded and executed when this step is completed. 
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$EDXASM Copy Code Function 



In the discussion of the link edit step, object modules were auto- 
matically included in the link edit, using the autocall feature of $LINK. 
In a somewhat similar manner, source statements may be merged into 
a source module at assembly time, using the "copycode" capability of 
$EDXASM. 

During the assembly operation, $EDXASM uses a language control data 
set. Figure B-3 in Appendix B is a listing of the system-supplied lan- 
guage control data set $EDXL. This data set consists of three main parts. 
Statements 10 through 2520 are error messages that may be required 
during assembly. Statements 2530 through 2880 are ^OVERLAY 
definitions. These are special control statements, used by the system 
loader to find the appropriate assembler overlay for each source instruc- 
tion encountered during an assembly. 

The third section consists of the two *COPYCOD definitions, statements 
2890 and 2900. $COPYCOD statements define logical volumes which 
may contain source data sets used as "copycode" source modules. The 
logical end of the language control data set is the **STOP**, statement 
2910. 

The system-supplied language control data set, $EDXL, has volumes 
ASM LIB and EDX002 defined as copycode volumes. When a COPY 
statement specifying the name of a source data set is encountered during 
the assembly of a source module, $EDXASM will search ASM LIB and 
EDX002 for a data set of that name, and will include the source state- 
ments in that data set in the assembly, if found. User source data sets 
sto^ed^on ASM LIB or EDX002 may be used as copycode modules in 
assemblies using $EDXL for a language control data set. If copycode 
data sets reside on other logical volumes, $EDXL must be modified 
(*COPYCOD statements added) to define those volumes to $EDXASM 
as copycode volumes, or a user-defined language control data set con- 
taining the new *COPYCOD definitions must be used for the assembly. 
A user-defined language control data set might be preferred to avoid 
altering $EDXL. 

Figures 16-43 through 16-50 will illustrate how to set up a user-defined 
language control data set, and how to code the COPY function in a user 
program. 

In Figures 16-43 through 16-45, the system-supplied language control 
data set, $EDXL, is modified to establish volume EDX003 as a copycode 
volume. The modified version is stored in the user-defined language 
control data set STATEDXL, leaving $EDXL undisturbed. Using 
$FSEDIT, the system-supplied language control data set $EDXL is read 
into the edit work data set, and EDIT mode (Primary Option 2) is 
entered. After scrolling to the bottom of the data set, the screen in 
Figure 16-43 is displayed. 
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o 



EDIT — SEDXL , ASMLIB 291( 

COMMAND INPUT --=-> 
02720 *OVERLAY $ASMOOOB ASMLIB 
02730 *OVERLAY $ASMOOOC ASMLIB 
02740 *0VERLAY $ASM000D ASMLIB 
02750 *OVERLAY $ASM000E ASMLIB 
02760 CONVTD 

02770 *OVERLAY $ASMOOOG ASMLIB 
02780 CONCAT TP STATUS 
02790 *0VERLAY $ASM000H ASMLIB 
02800 BSCLINE 

02810 *OVERLAY $ASM000I ASMLIB 
02820 *0VERLAY $ASM000Q ASMLIB 
02830 *0VERLAY $ASMEXI0 ASMLIB 
02840 *OVERLAY $ASM000S ASMLIB 
02850 *0VERLAY $ASM000T ASMLIB 
02860 *0VERLAY $ASM000U ASMLIB 
02870 *OVERLAY SASMOOOF ASMLIB 
02880 *OVERLAY $ASMOOOM ASMLIB 
02890 *COPYCOD ASMLIB 
02900 *COPYCOD EDX002 
02910 **STOP** 



1089)-- - COLUMNS 001 072 

SCROLL =--> HALF 
SBIO lODEF 
FIND FINDNOT 

FPCONV FADD FSUB FMULT FDIVD 
PRINTNUM GETVALUE READTEXT PRINTEXT CONVTB 



PLOTGIN GIN 



SCREEN XYPLOT YTPLOT 



BSCREAD BSCWRITE BSCOPEN BSCCLOSE BSCIOCB 



FORMAT 








FIRSTQ LASTQ 


NEXTQ 


DEFINEQ 




EXIODEV IDCB 


DCB 


EXOPEN 


EXIO 


SYSTEM STOREMAP 


DISK 


TIMER 


TAPE 


TERMINAL 








HOSTCOMM SENSORIO 


DDBSIO 


GETMAIN 


FREEMAIN 


ASMERROR SIDEF 


OTE 


SLE 




WHERES TCBGET 


TCBPUT 







***** **** 



BOTTOM OF DATA 



**************************************************** 



Figure 16-43. Program preparation (17) 



Using the insert line command, a copycode definition is placed in front 
of the * *STOP* * statement. 



EDIT - 
COMMAND 
02720 
02730 
02740 
02750 
02760 
02770 
02780 
02790 
02800 
02810 
02820 
02830 
02840 
02850 
02860 
02870 
02880 
02890 
02900 

02910 
***** 



001 072 
=-> HALF 



291( 1089) COLUMNS 

SCROLL 
SBIO lODEF 
FIND FINDNOT 

FPCONV FADD FSUB FMULT FDIVD 
PRINTNUM GETVALUE READTEXT PRINTEXT CONVTB 



PLOTGIN GIN 



SCREEN XYPLOT YTPLOT 



BSCREAD BSCWRITE BSCOPEN BSCCLOSE BSCIOCB 



- SEDXL , ASMLIB 
INPUT =---=> 
♦OVERLAY SASMOOOB ASMLIB 
♦OVERLAY SASMOOOC ASMLIB 
♦OVERLAY SASMOOOD ASMLIB 
♦OVERLAY SASMOOOE ASMLIB 
CONVTD 

♦OVERLAY SASMOOOG ASMLIB 
CONCAT TP STATUS 
♦OVERLAY SASMOOOH ASMLIB 
BSCLINE 

♦OVERLAY SASMOOOI ASMLIB 
♦OVERLAY SASMOOOQ ASMLIB 
♦OVERLAY SASMEXIO ASMLIB 
♦OVERLAY SASMOOOS ASMLIB 
♦OVERLAY SASMOOOT ASMLIB 
♦OVERLAY SASMOOOU ASMLIB 
♦OVERLAY SASMOOOF ASMLIB 
♦OVERLAY SASMOOOM ASMLIB 
♦COPYCOD ASMLIB 
♦COPYCOD EDX002 
♦COPYCOD EDX003 
♦♦STOP^^ 
**** BOTTOM OF DATA *************************************************** 



FORMAT 








FIRSTQ 


LASTQ NEXTQ 


DEFINEQ 




EXIODEV 


IDCB DCB 


EXOPEN 


EXIO 


SYSTEM 


STOREMAP DISK 


TIMER 


TAPE 


TERMINAL 








HOSTCOMM 


SENSORIO DDBSIO 


GETMAIN 


FREEMAIN 


ASMERROR 


SIDEF OTE 


SLE 




WHERES 


TCBGET TCBPUT 







Figure 16-44. Program preparation (18) 
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EDX003 is now defined as a copycode volume. The edit work data set 
is now written into data set STATEDXL, which was previously allocated 
for this purpose. 




Figure 16-45. Program preparation (19) 



16-32 SR30-0436 



In Figures 16-46 and 1647, a portion of code is extracted from the 
source data set STATSRC and stored on volume EDX003 in a data set 
named ROLL. This data set will be used as a copycode module. 

Again using $FSEDIT, the roll screen instructions from STATSRC 
are read into the work area, and identifying comments inserted at the 
beginning and end of the data set. This is accomplished by: 

1 . READ (Primary Option 3) STATSRC into work data set, 

2. EDIT (Primary Option 2) and block delete statements 10 through 
70, then statements 150 through 700 leaving only the "roll 
screen" statements 

3. Insert comments at top and bottom, resulting in the screen shown 
in Figure 16-46. 




Figure 16-46. Program preparation (20) 
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Now the COPY CODE module is written to data set ROLL (Figure 
16-47). 




Figure 16-47. Program preparation (21) 



In Figures 16-48 through 16-50, STATSRC is again read into the edit 
work area, and modified to use the COPY function. 

In Figure 16-48, STATSRC has been read into the work data set, and 
EDIT mode has been entered. 



EDIT --- EDITWOR 


K, EDX002 


COMMAND INPUT =■■- 


=> 


***** ***** TOP OF DATA 


00010 XMPLSTAT 


PROGRAM 


00020 


EXTRN 


00030 IMAGEBUF 


BUFFER 


00040 DSETNAME 


TEXT 


00050 lOCBl 


lOCB 


00060 I0CB2 


lOCB 


00070 


ATTNLIST 


[DflOOOSO START 


ENQT 


00090 


PRINTEXT 


00100 


PRINTEXT 


00110 


PRINTEXT 


00120 


PRINTEXT 


00130 


PRINTEXT 


[d5)0140 


DEQT 


00150 CHECK 


WAIT 


00160 


IF 


00170 GETIMAGE 


CALL 


00180 


IF 


00190 


MOVE 


00200 


PRINTEXT 


. 00210 


PRINTNUM 




70( 243) COLUMNS 001 072 

SCROLL --> HALF 
****************************************************** 

START 

$IMOPEN,$IMDEFN,$IMPROT,$IMDATA 

768, BYTES 

'VIDE01,EDX002' 

NHIST=0 

SCREEN=STATIC 

(END, OUT, $PF, STATIC) 

lOCBl 

■CLASS ROSTER PROGRAM' ,SPACES=15,LINE=1 

'HIT "ATTN" AND ENTER "END" TO END',SKIP=2 

' THE PROGRAM' 

'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 

' BRING UP THE ENTRY SCREEN' 

ATTNECB, RESET 

(ATTNECB,E0,l),GOT0,ENDIT 

SIMOPEN, (DSETNAME), (IMAGEBUF) 

(XMPLSTAT+2,NE,-1) 

ERRC0DE,XMPLSTAT+2 

'eiMAGE OPEN ERROR, CODE =' 

ERRCODE 



Figure 16-48. Program preparation (22) 



16-34 SR30-0436 



o 



The "DD" to the left of statement 80 and 140 will perform a block 
delete of the statements that will be brought in as copy code. In 
Figure 16-49, the ENTER key has been depressed, and the delete is 
done. 



PDIT -- 


- EDITWORK, EDX002 


63( 243) 


- COLUMNS 001 072 


COMMAND 


INPUT - 


==•> 




SCROLL ===>HALF 


***** 


***** TOP OF DATA 


****************************************************** 


00010 


XMPLSTAT 


PROGRAM 


START 




00020 




EXTRN 


$IMOPEN,$IMDEFN.$IMPROT,$IHDATA 




00030 


IMAGEBUF 


BUFFER 


768, BYTES 




00040 


DSETNAME 


TEXT 


'VIDEOl.ASMVOL' 




00050 


lOCBl 


lOCB 


NHIST=0 




00060 


I0CB2 


lOCB 


SCREEN=STATIC 




00070 




ATTN LI ST 


(END, OUT, $PF, STATIC) 




00150 


CHECK 


WAIT 


ATTNECB, RESET 




00160 




IF 


(ATTNECB,EQ,1),G0T0,ENDIT 




00170 


GET I MAGE 


CALL 


SIMOPEN , (DSETNAME) , ( IMAGEBUF) 




00180 




IF 


(XMPLSTAT+2,NE,-1) 




00190 




MOVE 


ERRC0DE,XMPLSTAT+2 




00200 




PRINTEXT 


•OIMAGE OPEN ERROR, CODE =* 




00210 




PRINTNUM 


ERRCODE 




00220 




GOTO 


ERRQUERY 




00230 




ENDIF 






00240 




CALL 


$IMDEFN,(I0CB2),( IMAGEBUF) 




00250 




ENQT 


I0CB2 




00260 




TERMCTRL 


BLANK 




00270 




CALL 


SIMPROT, (IMAGEBUF), 




00280 


^ 


CALL 


$IMDATA,( IMAGEBUF) 





Figure 16-49. Program preparation (23) 



In Figure 16-50, a COPY command is inserted, naming the copy code 
module ROLL. When the assembler encounters the COPY statement, 
it will go to the language control data set to find the copy code volume 
definitions and locate the data set containing the copy code module. 
The source statements in ROLL will be inserted at this point in the 
source module, and assembled as part of STATSRC. 
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HALF 


***** 


***** jop OF DATA 


****************************************************** 


00010 


XMPLSTAT 


PROGRAM 


START 


00020 




EXTRN 


$IMOPEN,$IMDEFN,$IMPROT,$IMDATA 


00030 


IMAGEBUF 


BUFFER 


768, BYTES 


00040 


DSETNAME 


TEXT 


•VIDE01,EDX002' 


00050 


lOCBl 


lOCB 


NHIST=0 


00060 


I0CB2 


lOCB 


SCREEN=STATIC 


00070 




ATTN LI ST 


(END, OUT, $PF. STATIC) 


00071 


* 






00072 




COPY 


ROLL 


00073 


* 






00150 


CHECK 


WAIT 


ATTNECB, RESET 


00160 




IF 


(ATTNECB,EQ,1),G0T0,ENDIT 


00170 


GETIMAGE 


CALL 


$IM0PEN, (DSETNAME), (IMAGEBUF) 


00180 




IF 


(XMPLSTAT+2,NE,-1) 


00190 




MOVE 


ERRC0DE,XMPLSTAT+2 


00200 




PRINTEXT 


■@IMAGE OPEN ERROR, CODE =' 


00210 




PRINTNUM 


ERRCODE 


00220 




GOTO 


ERRQUERY 


00230 




ENDIF 




00240 




CALL 


$IMDEFN,(I0CB2). (IMAGEBUF) 


00250 




ENQT 


I0CB2 



Figure 16-50. Program preparation (24) 

The edit work data set is saved back into STATSRC using the WRITE 
function (Primary Option 4), and the source module is ready for 
assembly. 
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Job Stream Procedure 



You have seen how, once a source module has been created ($EDIT1 N 
or $FSEDIT), the assembler ($EDXASM), linkage editor ($LINK), and 
load module formatter ($UPDATE) may each be invoked in turn, using 
the $L facility. Using a procedure file and $JOBUTI L, all three steps 
may be run as a single job stream. 






SEDIT1N 
5FSEDIT 



STEP 1: CREATE/MODIFY SOURCE MODULE 



SEDXASM 



STEP 4: LINK EDtT 
OBJECT MODULES 
(IF REQUIRED) 



STEP 2: ASSEMBLE SOURCE 
MODULE (PRODUCE OBJECT 
MODULE) 



SEDXLIST 
(OPTIONAL) 



STEP 3; PRODUCE 
ASSEMBLY LISTING 
(OPTJOIMAL) 



SLINK 

(AS REQUIRED) 



STEP5; FORMAT OBJECT MODULE INTO 
RELOCATABLE LOAD MODULE 
{EXECUTABLE PROGRAM) 



$UPDATE ■ 



SJOBUTIL 



RUN STEP 2, STEP 3, STEP 4, AND 
STEP 5 AS BATCH JOB STREAM 



Figure 16-51. Job stream procedure 

Appendix B, Figure B-4, is a listing of a batch job stream processor 
($JOBUTI L) procedure file. The statements in a procedure file are 
created using $EDIT1N or $FSEDIT, and saved in a data set. in this 
example, the procedure data set is STATPROC on EDX002. 

When $JOBUTI L is loaded, the operator is prompted for the name of 
a procedure file. 



o 



> $L SJOBUTIL 



4P, 00:05:32, LP= 5F00 



SJOBUTIL 

ENTER PROCEDURE (NAME, VOLUME) : ISTATPROC 

Figure 16-52. Program preparation (25) 
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In Appendix B, Figure B-4, the JOB command at statement 10 causes 
the display of a "job started" message on the loading terminal. 

> |$L $JOBUTIL| 

$JOBUTIL 4P, 00:05:32, LP= 5FQ0 



ENTER PROCEDURE (NAME, VOLUME) : ISTATPROC 



*** JOB - STATIC - STARTED AT 00:05:55 00/00/00 *** 
JOB STATIC 

Figure 16-53. Program preparation (26) 

The LOG command (statement 20, Figure B4) will cause the procedure 
file statements (other than internal comments) to print on the system 
printer. Statements 120 through 190 will load and execute the 
assembler. The source, work, and output data sets are specified in the 
DS commands. The PARM command at statement 170 directs the 
assembly listing to the system printer, and specifies STATE DXL as the 
language control data set for this assembly (STATEDXL contains the 
*COPYCOD statement for volume EDX003, where ROLL Is stored). 
The NOMSG command following the PARM prevents the $EDXASM 
load message from being displayed on the loading terminal, but the 
REMARK at statement 130 will appear. 



> |$L $JOBUflL 



$JOBUTIL 4P, 00:05:32, LP= 5F00 

ENTER PROCEDURE (NAME, VOLUME) : I STATPROCI 

*** JOB - STATIC - STARTED AT 00:05:55 00/00/00 *** 

JOB STATIC 

REMARK ASSEMBLY OF 'STATSRC STARTED 

Figure 16-54. Program preparation (27) 



The normal completion code for an error-free assembly is -1. The 
JUMP command (statement 200) tests the assembler completion code. 
If it is not equal to minus 1, the JUMP will transfer control to the 
label BADASM, which is defined by the LABEL command at state- 
ment 410. The REMARK at 420 would be displayed on the loading 
terminal, and the JUMP at 430 would transfer to label END, ending 
the job. 
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Assuming normal assembler operation, $JOBUTIL would continue 
with statements through 350, the link edit step. 

Through the PAUSE command, $JOBUTI L allows input of job control 
commands by an operator. To illustrate this capability, the link control 
data set is not specified in a DS command. Instead, the PAUSE at state- 
ment 300 will allow entry of the link control data set name. When the 
link procedure is entered, the two REMARK statements preceding the 
PAUSE will be displayed, along with the PAUSE operator instructions, 
and $JOBUTIL will wait for the operator to press ATTENTION and 
enter a command. 



> $L$JOB UTIL 



$JOBUTIL 4P, 00:05:32, LP= 5F00 

ENTER PROCEDURE (NAME, VOLUME) : ISTATPROCI 

*** JOB - STATIC - STARTED AT 00:05:55 00/00/00 *** 

JOB STATIC 

REMARK ASSEMBLY OF 'STATSRC STARTED 

REMARK LINK EDIT OF 'ASMOUT' OBJECT MODULE STARTED 

REMARK NAME OF LINK CONTROL DATA SET ? 

PAUSE-*-ATTN: GO/ENTER/ ABORT 

PAUSE 

Figure 16-55. Program preparation (28) 

The operator can continue (GO), enter a job control command 
(ENTER), or abort the job stream processor and end the job (ABORT). 
In this example, the operator wants to enter a command, so ENTER is 
requested. The operator Is prompted for the command and the com- 
mand operand. When GO is entered in response to the COMMAND 
prompt, $JOBUTIL continues. 
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> $L $JOBUTIL 



SJOBUTIL 4P, 00:47:17, LP= 5F00 



ENTER PROCEDURE (NAME, VOLUME) : ISTATPROC 



*** JOB - STATIC - STARTED AT 00:47:26 00/00/00 *** 

JOB STATIC 

REMARK ASSEMBLY OF 'STATSRC STARTED 

REMARK LINK EDIT OF 'ASMOUT' OBJECT MODULE STARTED 

REMARK NAME OF LINK CONTROL DATA SET ? 

PAUSE-*-ATTN: GO/ENTER/ABORT 

P AUSE 
> |ENTER 



ENTER COMMAND DS 



ENTER OPERAND LINKSTAT 



ENTER COMMAND GO 



Figure 16-66. Program preparation (29) 

$JOBUTIL allows secondary or nested procedures to be invoked from 
a primary procedure. To illustrate, the formatting job control state- 
ments have been defined as a nested procedure, stored in data set 
FORMPROC. 

00010 *"^**************'^* ***************************** *********** 

00020 * THIS IS A "NESTED" PROCEDURE, INVOKED FROM 

00030 * 'STATPROC BY THE 'PROC COMMAND. $JOBUTIL 

00040 * SUPPORTS ONE LEVEL OF NESTING. 

00050 * 

00060 REMARK FORMATTING OF 'LINKOUT' STARTED 

00070 PROGRAM $UPDATE 

00080 PARM $SYSPRTR LINKOUT STATPROG YES 

00090 NOMSG 

00100 EXEC 

00110 EOP 

Figure 16-57. Program preparation (30) 
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The primary procedure (Appendix B, Figure B-4), after testing for a 
successful link edit (JUMP command at statement 360), invokes the 
nested procedure FORMPROC by the PROC command at statement 
370. At the conclusion of the formatting step, control is returned to 
the primary procedure at statement 380. If $UPDATE executed 
properly, the job is ended without displaying the error message 
(REMARK at 390). 



> $L $JOBUTIL 



ENTER PROCEDURE (NAME, VOLUME) : ISTATPRQC 



*** JOB - STATIC - STARTED AT 00:05:55 00/00/00 *** 

JOB STATIC 

REMARK ASSEMBLY OF 'STATSRC STARTED 

REMARK LINK EDIT OF 'ASMOUT' OBJECT MODULE STARTED 

REMARK NAME OF LINK CONTROL DATA SET ? 

PAUSE-*-ATTN: GO/ENTER/ABORT 

PAUSE 



> ENTER 



ENTER COMMAND DS 



ENTER OPERAND LINKSTAT 



ENTER COMMAND GO 



REMARK FORMATTING OF 'LINKOUT' STARTED 
$JOBUTIL ENDED AT 00:10:18 

Figure 16-58. Program preparation (31) 

Figure B-5 In Appendix B is the $SYSPRTR output resulting from exe- 
cution of the $JOBUTI L procedure file STATPROC, including the 
assembly listing with the ROLL copy code statements successfully 
merged. 
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Section 17. Program Preparation Using $S1 ASM 



OBJECTIVES 



After completing this section, the student should be able to use 
$S1 ASM to assemble application programs written in Series/1 
assembler and/or Event Driven language. 



$S1ASM MACHINE READABLE MATERIAL 



Licensed program 57 19- ASA is distributed from PI D on a diskette with 
a volume name of ASAOOl. Included on the diskette are the following 
components: 

1. Series/1 macro assembler {$S1ASM) 

2. Linkage editor ($LINK) 

3. System definition file, procedure file, and link control file, for 
use in system generation using $S1ASM (5719-LM7 Macro 
Library is a prerequisite for system generation using $S1 ASM). 

4. Source, procedure, and link control files for an installation 
verification test program. 

$S1 ASM, unlike $EDXASM, is a macro assembler. It will assemble 
programs coded in Series/1 assembler language, such as USER exit 
routines, and when an operation code not in the Series/1 instruction 
set is encountered, it will search a macro library for a macro of that 
name. Licensed program 5719-LM7 is the macro library containing 
macro prototypes for all the Event Driven language statements, and 
must be installed if $S1 ASM is to be used for assembling Event 
Driven language programs, or to build tailored supervisors. 

$S1 ASM runs under control of the Event Driven Executive supervisor, 
so the system on which $S1ASM assemblies are run must also have the 
Event Driven Executive Basic Supervisor and Emulator installed. 
Program preparation aids and utilities are provided by the Event Driven 
Executive Utilities. 

Output object modules produced by $S1ASM assemblies must be 
processed by $LINK before being formatted into executable load 
modules by $UPDATE. 
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Note: For users who will be coding programs in the Event Driven lan- 
guage, the Program Preparation Facility is recommended. $EDXASM 
is a direct assembler for the Event Driven language; no macro processing 
is involved, and therefore performance is much higher than with 
$S1ASM and the 5719-LM7 Macro Library. 



INSTALLING $S1ASM 



$S1ASM OPERATION 



$EDIT1N 
$FSEDIT 



Installation procedures for the Series/1 macro assembler are in the 
Program Directory, shipped with the program from PID. As with the 
other Event Driven Executive program offerings, the $C0PYUT1 
utility is used to transfer the contents of PID diskettes to disk. If the 
installation instructions in the Program Directory are followed, 
$S1ASM will reside on logical volume ASM LIB on disk. 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Utilities, Operator Commands, and Program Preparation (SC34-0313), 
"Program Preparation Using $S1ASM." 

Figure 17-1 outlines the steps required to prepare programs for execu- 
tion using the $S1ASM macro assembler. 



STEP1: CREATE SOURCE MODULE. MAYBE 
SERIES/1 ASSEMBLER LANGUAGE CODE 
AND/OR (IF 5719-LM7 MACRO LIBRARY IS 
INSTALLED) EVENT DRIVEN LANGUAGE 



STEP 2: ASSEMBLE SOURCE MODULE 
(PRODUCES OBJECT MODULE) 



$JOBUTIL 




STEP 3: LINK EDIT OBJECT 
MODULE (REQUIRED) 



$UPDATE 



STEP 4: FORMAT OBJECT MODULE 
INTO RELOCATABLE LOAD MODULE 



Figure 17-1. $S1ASM program preparation overview 
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Data Set Requirements 



The program preparation steps illustrated in Figure 17-1 closely 
parallel those required for program preparation using $EDXASM 
(see Section 16, Figure 16-1), but with the following differences: 

1. The source module may contain Series/1 assembler language 
code and/or have references to user-written macros. 

2. The link edit step is mandatory, even if the assembled program has 
no external references. The object module produced by a 

$S1 ASM assembly cannot be formatted into a load module by 
$UPDATE without first being processed by $LINK. 



$S1 ASM uses three work data sets, which must be allocated by the 
user. 



> |$L $diskutT 



$DISKUT1 37P, 00:21:02, LP= 8300 
USING VOLUME EDX002 



COMMAND (?): |AL ASAH0RK1 2000 



DEFAULT TYPE = DATA - OK? |Y| 
ASAWORKl CREATED 



COMMAND (?) : lAL A$AW0RK2 2000 



DEFAULT TYPE = DATA - OK? |Y| 
ASAW0RK2 CREATED 



COMMAND (?): |AL ASAW0RK3~800 



DEFAULT TYPE = DATA - OK? [Y| 
ASAW0RK3 CREATED 



COMMAND (?): END 



$DISKUT1 ENDED AT 00:22:13 

Figure 17-2. Allocate work files 

The file sizes shown in Figure 17-2 are not unusually big for $S1ASM 
work data sets, and may have to be increased to accommodate a large 
assembly. Note that W0RK1 and W0RK2 must be of equal size. 

In addition to the three work files, $S1ASM also requires: 

• A source data set containing the statements to be assembled 

• An object output data set in which the object module produced by 
the assembly will be stored 

• If the source file contains macro references (Event Driven language 
statements or references to user-coded macros), at least one, and 
optionally two volume names must be supplied, on which reside the 
macro prototypes referenced in the source module 
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SOURCE MODULE 




OBJECT MODULE 
OUTPUT (INPUT 
FOR SLINK) 



Figure 17-3. $S1ASM data set requirements 



AT LEAST ONE 
REQUIRED IF MACRO 
INSTRUCTIONS 
CODED IN SOURCE 
MODULE 



At load time, the operator Is prompted for source, work, and output 
data set names. 



SISOURCE 



ASAWORKl 



> |$L $S1A$M,A$MLIB 

SOURCE (NAME, VOLUME) : 

WORKl (NAME, VOLUME): 

W0RK2 (NAME, VOLUME): 

W0RK3 (NAME, VOLUME): 

OBJECT (NAME, VOLUME): 

$S1ASM 88P, 00:24:19, LP= 8300 



ASAW0RK2 



ASAW0RK3 



ASMOBJ 



MACLIB1 (?): |EDX003 
MACLIB2 (?): 
ENTER OPTIONS (?): 
ENTER OUTPUT DEVICE NAME: 
CPAOOOI ASSEMBLER STARTED 

Figure 17-4. $S1ASM load 
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In Figure 17-4, volume EDX003 is specified as MACLIB1. When 
macro references are encountered in source data set SI SOURCE, 
volume EDX003 will be searched for the appropriate macro. Assuming 
S1 SOURCE contains Event Driven language statements, EDX003 
would contain the Event Driven Executive Macro Library. 

If required, a second volume may be specified (MACLIB2 {?): prompt), 
in which case the second volume would be searched if a required macro 
were not found on the volume specified as MACLIBL 

In Figure 17-4, the default assembler options are taken, and the output 
is defaulted to $SYSPRTR (null response to both prompts). With the 
default assembler options, $S1 ASM printed output can be voluminous, 
so you may wish to exercise options to suppress certain parts of the 
listing (see reading assignment for available options). 



$S1ASM/$J0BUTIL INTERFACE 



$S1 ASM, like $EDXASM, may be executed under control of the job 
stream processor, $JOBUTIL, using job control statements in a proce- 
dure file. In Figure 17-5, the job control statements in the procedure 
file at the right are the equivalents of the operator response sequence 
at the left. 




$L $$1A$M,A$MLIB 



SOURCE 
WORKl 
W0RK2 
WORKS 
OBJECT 
$S1ASM 



(NAME, VOLUME): 
(NAME, VOLUME): 
(NAME, VOLUME): 
(NAME, VOLUME): 
(NAME, VOLUME): 



JOB 
-^-PROGRAM 



SISOURCE 



ASAWORKl 



ASAW0RK2 



ASAW0RK3 



ASMOBJ 



H-DS 
-HDS 
-►DS 
-►DS 
-^DS 



88P, 00:02:39, LP= 8300 



FARM 



JSPEXMPL 

$S1ASM,ASMLIB 

SISOURCE 

ASAWORKl 

ASAW0RK2 

ASAW0RK3 

ASMOBJ 



EDX003 



MACLIBl (?): |EDX003 
MACLIB2 (?) 



ENTER OPTIONS (?) 

ENTER OUTPUT DEVICE NAME: 

Figure 17-5. $JOBUTIL procedure 




All program preparation steps other than the actual assembly are 
identical for $S1 ASM and for $EDXASM. See the appropriate topics 
in "Section 16. Program Preparation Using $EDXASM" for informa- 
tion on creating a source module, the link edit step, and formatting 
a linked object module into a relocatable load module. 
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Section 18. Session Manager 



OBJECTIVES 



At the conclusion of this section, the student should be able to: 

1. Describe basic Session Manager operation 

2. Use the Session Manager to run system utilities/program 
preparation programs 



SESSION MANAGER OVERVIEW 



Throughout this study guide, you have seen numerous examples of the 
use of the $L operator command to load programs and system utility 
programs, as illustrated in Figure 18-1. 

> $L $UTILITY, volume dsname, volume 




SUPERVISOR 



SUTILITY 



Figure 18-1. Load utility using $L 
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In general, the following statements are true about the use of the $L 
operator command: 

1. All data sets required by the program or utility being loaded, 
using the $L command, must be allocated by the user, prior to 
the load operation, using $DISKUT1. 

2. All data set names referenced by the program or utility to be 
loaded (which are not already specified in the DS= list of the 
PROGRAM statement) must be supplied by the operator each 
time the program or utility is loaded, even in a repetitive execu- 
tion environment such as program assembly and debug. 

3. All execution time options, such as output device, listing options, 
etc., are requested with each load of the program/utility, even if 
the responses are identical to previous executions and/or even 

if the default options (null entry) are acceptable. 

In "Section 16. Program Preparation Using $EDXASM", you were 
introduced to $JOBUTI L, the job stream processor utility. By alloca- 
ting ($DISKUT1) and then creating ($FSEDIT, $EDIT1N) a job control 
procedure data set, a job can be run under control of $JOBUTIL, 
as Illustrated in Figure 18-2 below. 



> $L $JOBUTIL, volume procname, volume 




SUPERVISOR 



$JOBUTIL 
procname 



PROGRAM 
DS 

EXEC 
EOJ 



$UTILITY, volume 
dsname, volume 



$UTILITY 



Figure 18-2. Loading utility using $JOBUTIL 
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$JOBUTI L, therefore, relieves the operator of the burden of having to 
remember and reenter each data set name and execution option with 
each reload of a utility or program. The data set names and options 
need only be entered once, into the job control procedure file. As 
long a** the data sets and options described in the procedure file 
match the execution environment desired, all the operator needs to 
know is the name of the procedure file. 

Although $JOBUTI L provides obvious productivity advantages over 
the direct loading of programs and utilities using the $L operator 
commands, a certain level of knowledge about the system must be 
attained before it can be used. 

A thorough understanding of $JOBUTI L operation, the meaning and 
organization of job procedure statements within a procedure file, and 
which programs or utilities might most profitably be run under 
$JOBUTI L are necessary before procedure files can be created. 

A procedure file, once created, is useful only so long as all data sets 
and operating parameters within that file exactly match the desired 
operation. If a single data set name or execution option is to be 
changed, the operator must 

1 . Use the $L command to load the program or utility directly, 
in which case, not only the changed data set name or option, 
but all data set names and options must be entered 

or 

2. Use $FSEDIT or $EDIT1N to make the required change in 
the procedure file 

In summary, the $L command is the most flexible facility for loading 
programs and utilities. At each load, the operator has the opportunity 
to change any or all options or data set names required by the program 
being loaded. The drawbacks of this method are that a large number 
of keystrokes is required, with the attendant possibility of operator 
input error; the operator must remember what may be a large number 
of data set names, all of which must be spelled correctly; and that all 
of the above is true each time the load is repeated, whether changes 
are required or not. 

On the other hand, $JOBUTI L, with its associated job control proce- 
dure files, is the most efficient means of loading programs and 
utilities, but lacks flexibility. If a change is required, the user must 
revert to the $L facility, or edit a procedure file, and must have a 
fair amount of system experience to create the procedures initially. 

The Session Manager is a productivity aid designed to take advantage 
of the efficiencies of $JOBUTIL, without losing the flexibility of the 
$L operator command. 
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The overall concept of Session Manager operation is illustrated in 
Figures 18-3 and 18-4. When a terminal user logs on (loads) the 
Session Manager, a menu of options is displayed on the screen. The 
operator enters the number associated with the option desired (Part A, 
Figure 18-3). 



1. LOADSUTILITY 

2. 

3. 



r/^ 



ENTER DATA 
SET NAME: 



C< 




SUPERVISOR 



SESSION MANAGER 



PROGRAM 
DS 

EXEC 
EOJ 



SESSION MANAGER 
CONTROL PROGRAM 

• PROCESS MENUS 

• BUILD JOB 
CONTROL 
PROCEDURE FILE 



Figure 18-3. Session manager overview (1) 

If the Utility being loaded requires data set names or execution param- 
eters, the Session Manager will display a parameter entry screen (Part B, 
Figure 18-3). 

The Session Manager uses the operator input from the option and 
parameter entry screens to build a $JOBUTI L job control procedure 
file (Parte, Figure 18-3). 
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After all inputs required to complete the procedure file have been 
entered, the Session Manager loads $JOBUTI L, passes it the procedure 
file, and the program is loaded, and executed under control of the job 
stream processor (Figure 18-4). 




PROGRAM 
DS 

EXEC 
EOJ 




SUPERVISOR 



SESSION MANAGER 



$JOBUTIL 



$UTILITY 



$UTILITY, volume 
dsname, volume 



Figure 18-4. Session manager overview (2) 

The next time the same option is chosen (Part A, Figure 18-3), the 
Session Manager will again display the parameter entry screen (Part B, 
Figure 18-3), allowing the operator to make changes, if desired. If 
no change from the previous execution is required, the operator just 
presses ENTER (null entry), and the Session Manager uses the parameters 
established in the previous execution again. 

Without knowledge of job stream processor operation or job control 
procedure statements, the operator is able to take advantage of the 
efficiencies of running under $JOBUTI L, while retaining the flexibility 
of easy alteration of execution parameters. 
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SESSION MANAGER OPERATING CONCEPTS 



Definition of Terms 

Menus 



Decision Tables 



Procedures 



READING ASSIGNMENT: IBM Series/1 Event Driven Executive 
Operator's Reference Message and Codes (SC34-1703), "Session 
Manager." 

Note: The following discussion is intended to convey the general 
concepts of Session Manager organization and operation, not the 
actual detail. The menus, procedures, and decision tables shown in 
the illustrations are abbreviated and simplified for clarity. 



In discussing the Session Manager, the term "menu" is frequently used, 
usually in the context of "Primary Option Menu", "Secondary Option 
Menu", or "Parameter Selection Menu." A menu is nothing more than 
a full screen image on a 4978/4979/3101 M2 Display. Primary and 
secondary option menus usually consist of a numbered list of possible 
functions. To invoke a function, the operator enters the number of 
that option. For parameter selection menus, the operator fills in data 
entry areas with data set names, run parameters, etc., for the utility 
being invoked. 



Decision tables are associated with option menus, and are used by the 
Session Manager to decide what to do when a given option in an 
option menu is selected. For every option in an option menu, there 
is a corresponding entry in that menu's associated decision table. That 
decision table entry may direct the Session Manager to display another 
option menu, to display a parameter selection menu, or, if the option 
selected requires no further menus, to submit a procedure file to 
$JOBUTI L for execution. 



A procedure is a $JOBUTI L procedure file used by the Session 
Manager to execute programs/utilities selected by entry of menu 
options. Parameters and data set names required by some utilities are 
filled in with entries from parameter selection menus, and the proce- 
dure is passed to $JOBUTI L and executed as a result of option menu 
decision table entries. 



18-6 SR 30-0436 



The relationship between option menus, option menu decision tables, 
parameter selection menus, and $JOBUTIL procedures is illustrated 
in Figures 18-5 through 18-7. In Figure 18-5, the operator has 
selected option 1, Text Editing, from the primary option menu. The 
corresponding entry in the primary option decision table directs the 
Session Manager to pass a procedure control file to $JOBUTIL 
which will load the full screen text editor, $FSEDIT. No secondary 
option menu is necessary, because $FSEDIT is the only text editor 
that the session manager supports, and therefore no choice 
of editors need be made. 



PRIMARY OPTION MENU 




1. TEXT EDITING 

2. PROGRAM PREP 

3. DISK UTILITIES 
etc. 



PRIMARY OPTION DECISION TABLE 



EXECUTE SFSEDIT PROCEDURE 



1. 

2. DISPLAY PROG PREP SECONDARY OPTION MENU 

3. DISPLAY DISK UTILITIES SECONDARY OPTION MENU 
etc. 



SJOBUTIL PROCEDURE FILE 

PROGRAM^ 

DS 

EXEC 

EOJ 



LOAD THE FULLSCREEN 
EDIT UTILITY SFSEDIT 



Figure 18-5. Session manager operation (1) 



$FSEDIT needs no parameters, so a parameter selection menu is not 
required. 

Note: $FSEDIT does require an edit work data set, but this data set 
is automatically allocated by the Session Manager when the terminal 
operator "logs on" to the session manager, and the name of the data 
set is automatically passed to the $FSEDIT procedure control file, so 
the operator is not required to supply the edit work data set name 
when the Text Editing (option 1) function is requested. 

In Figure 18-6, the operator has chosen option 3, Disk Utilities, on 
the primary option menu. Since there are several disk utility programs, 
the primary option decision table entry for option 3 directs the Session 
Manager to display a secondary option menu, so that the operator may 
choose which disk utility program to load. 
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PRIMARY OPTION MENU 



PRIMARY OPTION DECISION TABLE 




1. TEXT EDITING 

2. PROGRAM PREP 

3. DISK UTILITIES 
etc. 



SECONDARY 
OPTION MENU 



-" > 1 

1. $blSKUT1 

2. $DISKUT2 

3. $C0PYUT1 
etc. 



1. EXECUTE SFSEDIT PROCEDURE 

2. DISPLAY PROG PREP SECONDARY OPTION 



lENU 



'3. DISPLAY DISK UTILITIES SECONDARY O PTION MEN U 
etc. 






SECONDARY OPTION DECISION TABLE 



M. EXECUTE $DISKUT1 PROCE DURE 

2. EXECUTE $DISKUT2 PROCEDURE 

3. EXECUTE $C0PYUT1 PROCEDURE 
etc. 



SJOBUTIL PROCEDURE FILE 



PROGRAM 

EXEC 

EOJ 



LOAD DISK 
UTILITY DISKUT1 



Figure 18-6. Session manager operation (2) 



On the secondary option menu for the disk utilities, the operator has 
chosen option 1, $DISKUT1. Because $DISKUT1 requires no execution 
parameters or data set names, the secondary option menu decision 
table entry for option 1 directs the Session Manager to pass the 
$DISKUT1 load procedure to $JOBUTIL, which will result in the 
loadof $DISKUT1. 

In Figure 18-7, the operator has chosen primary option 2, Program 
Preparation. Several different programs and utilities may be used 
in program preparation, so the primary option menu decision table 
entry directs the Session Manager to display the program preparation 
secondary option menu. 



18-8 SR 30-0436 



PRIMARY OPTION MENU 




1. TEXT EDITING 

2. PROGRAM PREP 

3. DISK UTILITIES 
etc. 



PRIMARY OPTION DECISION TABLE 



1. EXECUTE $FSEDIT PROCEDURE 

2. DISPLAY PROG PREP SECONDARY OPTION 

3. DISPLAY DISK UTILITIES SECONDARY OPTION 
etc. 



SECONDARY OPTION MENU 






SECONDARY OPTION DECISION TABLE 



1. $EDXASM ASSEMBLY 

2. $S1ASM ASSEMBLY 

3. $COBOL COMPILE 
etc. 



1. DISPLAY SEDXASM PARM SELECTION MENU 



- EXECUTE SEDXASM PR OCEDURE 
DISPLAY SSIASM PARM SELECTION 

- EXECUTE SSIASM PROCEDURE 
DISPLAY SCOBOL PARM SELECTION 

- EXECUTE SCOBOL PROCEDURE 



etc. 



PARAMETER SELECTION 
MENU 




SOURCE ■_-.::;> SI SOURCE' 

OUTPUT ::::;:. ASMOBJ^ 

OPTIONS ill^NOLISf 





SJOBUTIL PROCEDURE FILE 



PROGRAM ^ 




DS 




DS 


LOAD 


DS 


SEDXASM 


PARM 


ASSEMBLER 


EXEC 




EOJ >! 





Figure 18-7. Session manager operation (3) 



On the secondary option menu, the operator chooses option 1, 
$EDXASM assennbly. Since input and output data set names, as well 
as execution options may vary from one assembly to the next, the 
first part of the secondary option menu decision table entry for 
option 1 directs the Session Manager to display a parameter selection 
menu for $EDXASIVi. 

If no previous assembly has been done, the data set name and option 
entry areas on the screen will appear blank, and will be filled in at 
this time by the operator. If a previous assembly has been done, the 
data set names and assembler options used for the last assembly will 
be displayed. The operator may change items as necessary, or, if 
everything is the same as the previous assembly, may use all the same 
parameters, by pressing ENTER (null entry). 
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In any event, when the ENTER key is pressed, the Session iVlanager 
transfers the data from the parameter selection menu to the job control 
procedure. Then, under direction of the second part of the secondary 
option menu decision table entry for option 1, the procedure is passed 
to $JOBUTI L for execution. 



USING THE SESSION MANAGER 



The Session Manager is, to a large extent, self-tutoring, and is most 
easily learned by actually using it. However, in an attempt to convey 
at least an idea of what it is like to use the session manager, the three 
option selection sequences illustrated in Figures 18-5 through 18-7 
will be repeated, this time using actual screen images that an operator 
would see while performing these operations. 



LOADING THE SESSION MANAGER 



A 4978/4979/3101 M2 terminal is logically attached to the Session 
Manager by entering the $L command shown in Figure 18-8. 




Figure 18-8. Session manager example (1) 

Note: The Session Manager may be automatically brought up on all 
4978/4979/3101 M2 terminals on the system, at IPL See the reading 
assignment for details. 
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When the load command is honored, the LOGON screen in Figure 18-9 
will appear. The session manager requires a unique 1 to 4 character 
user ID for each user. For this exercise, the characters XiVlPL are 
entered. 




Figure 18-9. Session manager example (2) 



The "ALTERNATE SESSION MENU" prompt below the user ID 
prompt would be used if you had created your own menus, decision 
tables, and procedures for use with the Session Manager. 
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Data Set Allocation 



After entering the user ID and pressing the ENTER key, the screen 
shown in Figure 18-10 appears. 




Figure 18-10. Session manager example (3) 



When a user logs on to the Session Manager, the Session Manager 
allocates six data sets on EDX003. The names, sizes, and functions 
of these data sets are shown in Figure 18-11. 
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SIZE 
(records) 



SSMPxxxx 30 



SSMWxxxx 30 



USED BY THE SESSION MANAGER TO SAVE 
PARAMETERS ENTERED FROM PARAMETER 
SELECTION MENUS DURING PREVIOUS SESSIONS 
UNDER SAME USER ID 

USED BY SESSION MANAGER TO SUBMIT PROCE- 
DURES TO SJOBUTIL FOR EXECUTION 

USED AS A WORK FILE FOR: 



SSMExxxx 400 

SSMIxxxx 400 

$SM2xxxx 400 

$SM3xxxx 250 

Figure 18-11. Session manager data set allocation 
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The first four characters of each data set name is as depicted in 
Figure 18-11. The last 1 to 4 characters will be the user ID entered 
on the LOGON screen (Figure 18-9). In this case, the data sets 
would be named $SMPXMPL, $SMWXMPL, etc. 

When attempting to allocate data sets, the Session Manager first checks 
to see if the data sets already exist, and if they do, will use those already 
there. If a user has allocated data sets (with the proper names) using 
$DISKUT1, the user-allocated data sets will be used. This allows a 
user to define larger data sets than would the Session Manager, if the 
sizes allocated by the Session Manager prove too small. 
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After data sets have been allocated, the primary option menu in 
Figure 18-12 will appear. 




Figure 18-12. Session manager example (4) 

The operator enters option 1 for TEXT EDITING, and the screen in 
Figure 18-13 appears. 



30P, LP= 9100 

DSl HAS NOT PREVIOUSLY BEEN USED 
AS AN EDIT WORK DATA SET. 

IS IT OK TO USE IT NOW? [7^ 




Figure 18-13. Session manager example (5) 
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The "IS IT OK TO USE IT NOW?" prompt appears because $SMEXMPL, 
the text editor work data set, was just allocated, and the data is not 
in a format $FSEDIT recognizes. After once being used for this purpose, 
the prompt will not reappear. 

After responding YES to the prompt, the primary option menu for 
$FSEDIT is displayed, just as it would if $FSEDIT had been loaded 
using the $L operator command (Figure 18-14). 




Figure 18-14. Session manager example (6) 



When option 8, "TERMINATE $FSEDIT" is entered, the screen in 
Figure 18-15 appears. 




Figure 18-15. Session manager example (7) 
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After a utility loaded by the Session Manager is ended, the ENTER 
key must be pressed to return to Session Manager control. Control is 
returned to the last Session Manager menu displayed before the utility 
was loaded, in this case, the Session Manager primary option menu 
(Figure 18-16). 




Figure 18-16. Session manager example (8) 

This time, the operator enters option 3 for DISK UTILITIES, bringing up 
the data management utilities' secondary option menu in Figure 18-17. 




Figure 18-17. Session manager example (9) 
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Entering option 1 on the secondary option menu results in the load of 
$DISKUT1, as shown in Figure 18-18. 




Figure 18-18. Session manager example (10) 

When the utility is ended, and the ENTER key depressed, the Session 
Manager regains control, returning to the last screen displayed 
(Figure 18-19). 




Figure 18-19. Session manager example (11) 
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To do Program Preparation, the operator now must return to the primary 
option menu. To return to a previous screen, press PF3 (Figure 18-20). 




Figure 18-20. Session manager example (12) 

When option 2 is entered on the primary option menu, the program 
preparation secondary option menu is displayed (Figure 18-21). 




Figure 18-21. Session manager example (13) 
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The operator enters option 1, the $EDXASM assembler, and the 
$EDXASM parameter selection menu is displayed (Figure 18-22). 







Figure 18-22. Session manager example (14) 



In Figure 18-22, the source input, object output, and optional 
parameter entry areas are blank. This indicates that this is the first 
time that $EDXASM has been invoked under this user ID (XMPL). 
The Session Manager saves input parameters between executions of 
a program within a session, and across sessions of the same user ID 
(data set $SMPxxx in Figure 18-11). If $EDXASM had previously 
been used with user ID XMPL, the previously entered parameters 
would appear in Figure 18-22. 
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The operator enters the parameters as shown in Figure 18-23. 




Figure 18-23. Session manager example (15) 



Before pressing the ENTER key, assume the operator notices that 
the output data set name is ASMOUT, when it should actually be 
ASMOBJ. The operator can, using the cursor movement keys, position 
the cursor so as to correct the erroneous spelling, or can press PF2, 
resulting in the screen in Figure 18-24. 




Figure 18-24. Session manager example (16) 
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PF2 returns a menu to the state it was in when it was initially displayed, 
before operator entries were made to alter it. PF2 may be pressed any 
time before pressing ENTER, which signals completion of entry to 
a screen. 

After reentering the parameters, this time with the correct spelling for 
the object output data set name, the $EDXASM parameter selection 
menu looks like Figure 18-25. 




Figure 18-25. Session manager example (17) 

Notice that the operator is not required to enter the name of a work 
data set. The Session Manager will supply the name of one of the work 
data sets that were automatically allocated during LOGON of the session. 
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Before pressing ENTER, assume the operator has mounted a diskette 
volume in the diskette device at address X'02', and wishes to bring the 
volume on line. This requires access to the system operator commands. 
Any time a Session Manager menu is displayed, the operator can get 
into system command mode by pressing PF1. When PF1 is pressed, 
the currently displayed menu is replaced with the screen shown in 
Figure 18-26. 




ENTERING SYSTEM COMMAND MODE - 
TO REENTER THE SESSION MANAGER, 
DEPRESS THE ATTN KEY AND ENTER "SSM" 




Figure 18-26. Session manager example (18) 

The operator varies the volume on line, and enters $SM to return to the 
Session Manager. 




entering system command mode - 
to reenter the session manager, 
d epress the a ttn key and enter "$sm" 
> isvaryon "02] 
smvol online 
> [$sm1 





Figure 18-27. Session manager example (19) 
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When the ENTER key is pressed to enter the $SM command, the 
Session Manager returns to the same menu that was displayed at the 
time system command mode was entered (PF1 was pressed). 




Figure 18-28. Session manager example (20) 



Since all $EDXASM parameters have been entered, the operator 
presses the ENTER key to submit the job for execution. 




Figure 18-29. Session manager example (21) 
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After the assembly is complete, the operator presses ENTER to return 
to the Session Manager, which brings up the $EDXASM parameter 
selection menu, the last menu displayed. 




Figure 18-30. Session manager example (22) 



Pressing PF3 twice backs out through the two previous screens, as 
shown in Figures 18-31 and 18-32. 



SSMM02 


: SESSION 


MANAGER PROGRAM PREPARAi 


riON 


fNTER/St 


rLECT PAR, 


^METERS : 






iELECT OP 
1 - 


TION ==> 
SEDXASM COMPILER 






2 - 


SSIASM ASSEMBLER 






"? - 


SCOBOL COMPILER 






4 - 


SFORT FORTRAN COMPILER 






5 - 


SLINK LINKAGE EDITOR 






6 - 


SUPDATE 






7 - 


SUPDATEH (HOST) 
SPREFIND 






9 - 


SEDXASM/SLINK/ SUPDATE 






10 - 


SPLI COMPILER/SLINK/SUPDATE 



OPTION MENU- 



PRESS PF3 TO RETURN 



Figure 18-31. Session manager example (23) 
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Figure 18-32. Session manager example (24) 

To end the session, the operator again presses PF3, while the primary 
option menu is displayed, which results in the prompt in Figure 18-33. 




Figure 18-33. Session manager example (25) 
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If the operator replies YES to the prompt, none of the data sets 
allocated under this user ID at the beginning of the session will be 
deleted. If, for example, you had allocated work data sets larger than 
those normally allocated by the Session Manager (using $DISKUT1), to 
accommodate particularly large assemblies or compiles, entering YES 
would prevent those data sets from being deleted, and the next time 
you wished to log on with the same ID, you would not have to first 
use $DISKUT1 to allocate your oversize work files. 

Entering NO results in deletion of all the data sets under this ID except 
for $SMPxxxx. This data set is retained, and used to save parameters 
for future sessions under the same ID. For example, if the operator 
were ever again to log on with ID XMPL, and through the option 
menus, choose program preparation and $EDXASM assembly, when the 
$EDXASM parameter selection menu was displayed, the parameters 
would be those last entered during this session. 

Assuming NO was entered, the message in Figure 18-34 would be dis- 
played during deletion of the data sets, followed by the LOGON 
screen in Figure 18-35. 




Figure 18-34. Session manager example (26) 
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Figure 18-35. Session manager example (27) 

To terminate the session, the operator enters LOGOFF in the command 
input area, and presses ENTER (Figure 18-36). 




o 



Figure 18-36. Session manager example (28) 
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Appendix A. SYSGEN Listings 



LOG tSYSPRTR 

*««= JOB - $SUPPREP - STARTED AT 03:22:^5 00/00/00 *** 



JOB 


SSUPPREP 


PROGRAM 


SEDXASMtASMLIB 


NOMSG 




PARM 




OS 


$E0XDEFSiEDX002 


DS 


ASMWaRKtEDX002 


DS 


ASMQBJ»E0X002 


6XEC 





Figure A-1 . Procedure file statements controlling assembly 



EOX ASSEMBLER STATISTICS 

SOURCE INPUT - $EDXDEFS»E0X002 
WORK DATA SET - ASMWORK tEDX002 
OBJECT MODULE - ASM03J »EDX002 
DATE: 00/00/00 AT 03:23:32 
ASSEMBLY TIME: 35 SECONDS 
STATEMENTS PROCESSED - 30 

NO STATEMENTS FLAGGED 



SOURCE STATEMENT 



$EDXDEFStEDX002 



(5719-XX4J-V3.0.0 



0/00/ 3:23 



0000 
0000 



CSECT 
DATA 



F«0» 



o 



0002 


0000 


0000 


0000 


0000 


0000 


0052 


OOOA 


OOOA 


OOOA 


0000 


0000 


005C 


0000 


0000 


0000 


0020 


FFFF 


0066 


0008 


0010 


0014 


0000 


0000 


0070 


0000 


0000 


0000 


0098 


OOEC 


007A 


0140 


0194 


0198 


019C 


OlAO 


0084 


01A4 


00E8 


013C 


0190 


0194 


008E 


0198 


019C 


OlAO 


01A4 


0000 


0098 


FFFF 


3000 


FFFF 


8000 


FFFF 


00A2 


8000 


FFFF 


8000 


FFFF 


8000 


OOAC 


FFFF 


3000 


FFFF 


8000 


FFFF 


0006 


8000 


FFFF 


8000 


FFFF 


8000 


OOCO 


FFFF 


8000 


FFFF 


8000 


FFFF 


OOCA 


8000 


FFFF 


8000 


FFFF 


8 000 


0004 


FFFF 


8000 


FFFF 


8000 


FFFF 


OODE 


8000 


FFFF 


8000 


FFFF 


8000 


00E8 


FFFF 


8000 


FFFF 


80U0 


FFFF 


00F2 


8000 


FFFF 


8000 


FFFF 


8000 


OOFC 


FFFF 


8000 


FFFF 


8000 


FFFF 


0106 


8000 


FFFF 


8000 


FFFF 


8000 


0110 


FFFF 


8000 


FFFF 


8000 


FFFF 


01 lA 


3000 


FFFF 


8000 


FFFF 


8000 


0124 


FFFF 


8000 


FFFF 


8000 


FFFF 


012E 


8000 


FFFF 


8000 


FFFF 


8000 


0138 


FFFF 


8000 


FFFF 


8000 


FFFF 


0142 


8000 


FFFF 


BOOO 


FFFF 


8000 


014C 


FFFF 


3000 


FFFF 


8000 


FFFF 


0156 


8000 


FFFF 


8000 


FFFF 


8000 


0160 


FFFF 


8000 


FFFF 


8000 


FFFF 


016A 


8000 


FFFF 


8000 


FFFF 


8000 
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Figure A-2. Assembly statistics and listing (1 of 6) 
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Figure A-2. Assembly statistics and listing (2 of 6) 
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Figure A-2. Assembly statistics and listing (3 of 6) 
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Figure A-2. Assembly statistics and listing (4 of 6) 
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SSYSLOG 


ENTRY 


052E 


rA4979 


EXTRN 




104979 


EXTRN 




SSYSPRTR 


ENTRY 


OFAC 



Figure A-2. Assembly statistics and listing (5 of 6) 
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SYSGEN Listings A-5 



OSPLYl 


ENTRY 


0708 


l\^97Q 


EXTRN 




TRASCII 


EXTRN 




SSYSLOGA 


ENTRY 


08CC 


lATTY 


EXTRN 




lOTERM 


EXTRN 




TRE3ASC 


EXTRN 




SSYSLOGB 


ENTRY 


OADE 


lAACCA 


EXTRN 




103101 


EXtRN 




LINEPRTR 


ENTRY 


0094 


IAA973 


EXTRN 




I0'r974 


EXTRN 




IA4974 


EXTRN 




SSYSCOM 


ENTRY 


115A 


$EDXPTCH 


ENTRY 


117A 



COMPLETION CODE = -I 

Figure A-2. Assembly statistics and listing (6 of 6) 



JUMP 

PROGRAM 

NOMSG 

PARM 

OS 

OS 

OS 

EXEC 



ENDJ0B»GT»4 
SLINKtEOXOUZ 

SSYSPRTR 
LINKCNTLfEDX002 
LEW0RKltE0X002 
LEWORKZtEOXOOZ 



Figure A-3. Loading link editor 



SLINK EXECUTION CONTROL RECORDS 

FROM LINKCNTL»EDX002 
« 

* EVENT DRIVEN EXECUTIVE - VERSION 3t MODIFICATION LEVEL 
4 

« COMMENTS MAY BE INCLUDED BY AN •*♦ IN COLUMN I * 

* USE THIS TECHNIQUE TO OMIT UNNEEOEO MODULES * 

OUTRUT SUPVLINKfEDX002 ENTRY=$START 
«> 

« SUPERVISOR SUPPORT * 



INCLUDE E0XSYS»XS3002 *0« SYSTEM TABLES AND WORK AREAS 

INCLUDE ASM03JtEDX002 *0* OUTPUT FROM USER SYSTEM GENERAT IQf^ 

INCLUDE E0XSVCXfXS3002 *0»K# TASK SUPERVISOR tXLI 

* INCLUDE EOXSVCXUfXS30O2 *OtL« TASK SUPERVISOR «UN-XL) 
INCLUDE $DBUGNUCtXS3002 *G* RESIDENT SDEBUG SUPPORT 
INCLUDE EDXALUtXS3002 *0* EOL INSTRUCTION EMULATOR 
INCLUDE E0XSTART,XS3002 *0* INITIALIZATION C ERROR HANDLER 

« 

* DEVICE SUPPORT — DISKJETTEIS * 

INCLUDE DISKI0tXS3002 «M* BASIC DISKIETTE) SUPPORT 

INCLUDE D4962'V»XS3002 *M* '►962/4964 DISK(ETTEI SUPPORT 

* INCLUDE D4963AfXS3002 *M* 4963 SUBSYSTEM SUPPORT 

* INCLUDE 04966Af XS3002 «M* 4966 MAGAZINE SUPPORT 
« 

<■ DEVICE SUPPORT — TAPE * 



* INCLUDE 04969A,XS3002 



*H< 



BASIC TAPE SUPPORT 



* DEVICE SUPPORT — TERMINALS * 



INCLUDE 

INCLUDE 



E0XTIO»XS3O02 
EDXTI0U»XS3002 



*ltK« BASIC TERMINAL SUPPORT (XL) 
*lfL« BASIC TERMINAL SUPPORT (UN-XL) 



Figure A-4. Link control file (1 of 8) 
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INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 



EDXTERMQ»XS3002 i'lfK* ENQT/OEQT C TERMINAL QUEUEING (XL) 
EDXTRM0UtXS3002 *ltL* ENQT/DEOT L TERMINAL QUEUEING (UN-XL) 
I0S'*979tXS3002 *M,K* 4978/4979 DISPLAY SUPPORT (XL) 
IOS4979U»XS3002 «MiL« 4978/4979 DISPLAY SUPPORT (UN-XL) 
I0S4974.XS3002 *M»K* 4973/4974 PRINTER SUPPORT (XL) 
I0S4974UfXS3002 «M,L* 4973/4974 PRINTER SUPPORT (UN-XL) 
I0STERM,XS3002 *2=> REQUIRED FOR TTY, ACCAt 4013 t 2741 
«M* ASR 33/35 TELETYPEWRITER SUPPORT 
*3* ASCII ACCA TERMINAL SUPPORT 
«MtO« 3101 BLOCK MODE SUPPORT 
«M* SERIES/1 - SERIES/1 SUPPORT 
*M* GPIB SUPPORT 

«M* DIGITAL I/O TERMINAL SUPPORT 
*M* 2741 TERMINAL SUPPORT 
*MtN* VIRTUAL TERMINAL SUPPORT 



I0STTY»XS3002 

I0SACCAtXS30G2 

I0S3101»XS3002 

ICSSlSlfXS3002 

IOSGPIBtXS3002 

I0S4013.XS3002 

I0S2741iXS3002 

10SVIRT,XS3002 



* TERMINAL SUPPORT ~ TRANSLATION TABLES * 



INCLUDE TRASCIIfXS3002 

INCLUDE TRE8ASCtXS3002 

* INCLUDE TREBCD»XS3002 

* INCLUDE TRCRSP,XS3002 



*4,P* TELETYPEWRITER TRANSLATION 
*3t?* MIRROR IMAGE ASCII TRANSLATION 
<=5* 2741 EBDC Ti^ANSLATION 
*5* 2741 CORRESPONDENCE TRANSLATION 



* TERMINAL SUPPC°t — SPOOLING * 

* 

INCLUDE I0SP00LfXS3002 *M* SPOOLING SUPPORT 

««*««*« ***«««*«*«*«««^t *«:::****«***** *«:****.>*««*«*«<:*4 

* DEVICE SUPPHRT — TIMERS * 



INCLUDE 
INCLUDE 



EDXTIMERtXS3002 *6* 
EDXTIMR2,XS3002 *6* 



4953/4955 TIMER (7340) SUPPORT 
4952 TIMER SUPPORT 



* DEVICE SUPPORT ~ BINARY SYNCHRONOUS COMMUNICATIONS * 

4ci»4s4i4i«4i4:>^4:4<4i4:4--«;::4:«4<4:4<4<4:4:4:4:4:4<4l4'4:4<4<;:i»4:4:4:«4:4:4<4:4:4:4:4t4:4l4:4i4:«««« 



* INCLUDE BSCAMfXS3002 

* INCLUDE BSCAMU.XS3002 

* INCLUDE TPCOM,XS3002 



*7,K* BISYNC COMM. ACCESS SUPPORT (XL) 
*7,L* BISYNC COMM. ACCESS SUPPORT (UN-XL) 
*8* HOST COMMUNICATION SUPPORT 



4t**<!*4:««:«***«*4!4=*****4:****4:*«*««4:*4:*4t4:«4!**4:4'*4:4!<:#4'«4i 

* DEVICE SUPPORT — SENSOR INPUT/OUTPUT * 

4l4l*«*4:4!4=*4:*4!4i4:4:4'4!**4:*4!*4:*4:4:4'*4!*4!4'«***4:4l4:***4!«!#4!*4!«** 



INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 



SBCOM,XS3002 *9* BASIC SENSOR I/O SUPPORT 
I0L0ADER.XS3002 ^gtK* SENSOR I/O DEVICE OPEN (XL) 
I0L0A0RUfXS3002 «9fL* SENSOR I/O DEVICE OPEN (UN-XL) 



SBAItXS3002 
SBA0fXS3002 
SBDIDCfXS3002 
SBPI,XS3002 



*M* ANALOG INPUT SUPPORT 

*M* ANALOG OUTPUT SUPPORT 

*M* DIGITAL INPUT/OUTPUT SUPPORT 

*M» PROCESS INTERRUPT SUPPORT 



4:4t4t4:**4!<t4:4i4:4:4:4:«4:4!4'4'4:4:*4:****4:4:*4:4:4>4!***4:**«*4'4'4!4!4'4'4:4;** 

* DEVICE SUPPORT — EXIO CONTROL * 

4:«:»4:4i4:4i:»«:»«:<l4:4::»4<«i4:4'4<4:4:4l4:4'4<4<4<«<4:«4:4:4:«:<::»4'4:4l4:4:4::»4<4<4:4l4l4l4:« 



« INCLUDE 



IOSEXIOfXS3002 



EXIO DEVICE CONTROL SUPPORT 



4:4i«:»«:»4:4:4::»4:4:4:4i4:4i«4i«4:4:4c4:4<4s4i4:4<4<4::»4i4i4:4:4>4>4<4:4:4:4:«4e«i«4:<:4i#4:4: 

* SYSTEM SUPPORT — ERROR LOGGING * 

4i4:4:3;--<:4l4<4:4:4:<i4<«»4:«4i4:4:4<4:4:4:4:4<4:4:4:4:4:4:4:4<4:4:4:4i4:4<4<4<$4'4<>;i4<4:4:4::»<:4l 



INCLUDE SYSLOGf XS3002 *A* 
INCLUDE NOSYSLOGtXS3002 *A* 
INCLUDE CIRCBUFFtXS3002 *B* 



I/O ERROR LOGGING 
NO I/O ERROR LOGGING 
PROGRAM/MACHINE CHECK LOGGING 



«;4:4<4:4:4i4c4:4i4:4i<:4i4:«4i«4:4:4<4:4:4:«4:4:4<4e«4:4:4e4:4:«4:4:4'4:4:<:4:4:4i4:4:4:4<4:4i4:4: 

« OPTIONAL FUNCTION SUPPORT * 

4t;»4'4:4:«4:4:4i4<4t4i4:4:4:4[4:4<4:4<4s4:4:4c4:4:4<4:4:4:4:«4<4<<:4:4s4:4:4:«4:>:i«4:4:4:4i4i4:4::» 



INCLUDE RLOAD£R»XS3002 «C.K« RELOCATING PROGRAM LOADER (XL) 

I 

I 

I 

I 

I 



[NCLUDE 
INCLUDE 
[NCLUDE 
[NCLUDE 
[NCLUDE 



RLOADERUf XS3002 *CtL* RELOCATING PROGRAM LOADER (UN-XL) 
EDXFLOATfXS3002 *0* FLOATING POINT ARITHMETIC 

*0* FOR SYSTEMS WITHOUT FLOATING POINT 
*E* EBCDIC/FLOATING POINT CONV. 
*F* QUEUE PROCESSING SUPPORT 



N0FL0ATfXS3002 
E8FLCVT,XS3002 
QUEUEIO,XS30O2 



^4t4"4!4'*4!«*«4'4>*«««4>**4:<=*4:**4'4:4:t=4!4.-**4!4!**4:*««««*«*«**4> 

SYSTEM SUPPORT — INITIALIZATION * 

?*4:4i««4'*4:**4:*4;4'4:4!****4:4--*«'<:**«*4!*4:4>4'«:*4>***4<*4!**«**4: 



INCLUDE 
INCLUDE 



EOXINITtXS3002 *H* 
DISKINIT.XS3n02 *M« 



SUPERVISOR INITIALIZATION 
DISK(ETTE) INITIALIZATION 



Figure A-4. Link control file (2 of 8) 



SYSGEN Listings A-7 



* INCLUDE 


TAPEINITfXS3002 *M« 


TAPE INITIALIZATION 


INCLUDE 


L0ADINIT,XS'3002 *C* 


PROGRAM LOADER INITIALIZATION 


* INCLUDE 


RW4963IDf XS3002 *M* 


4963 FIXED HEAD REFRESH SUPPORT 


INCLUDE 


TtRHINITiXS3002 *1* 


TERMINAL INITIALIZATION 


INCLUDE 


INIT4978fXS3002 *M* 


4973 DISPLAY INITIALIZATION 


* INCLUDE 


INIT't013fXS3002 *M* 


DIGITAL I/O TERMINAL INITIALIZATION 


INCLUDE 


$ACCARAMtXS3002 *3* 


ACCA MULTI-LINE ADAPTER RAM LOAD 


* INCLUDE 


BSCINITtXS3002 *7« 


BISYNC JBSCAM) INITIALIZATION 


* INCLUDE 


TPINIT,XS3002 «8* 


HCF (TPCOMI INITIALIZATION 


INCLUDE 


TIMRINITfXS3002 *6* 


4953/4955 TIMER INITIALIZATION 


« INCLUDE 


CL0KINIT,XS3002 *6* 


4952 TIMER INITIALIZATION 


* INCLUDE 


SBI0INirtXS3002 *M* 


SENSOR I/C INITIALIZATION 


* INCLUDE 


EXI0INITfXS3002 «M* 


EXIO INITIALIZATION 


* INCLUDE 


SlSlINITtXS3002 «M,Q 


<= SlSl INITIALIZATION 


END 








*«*«* UNRESOLVED EXTERNAL REFERENCES 


WXTRN 


EXOPEN 






WXTRN 


SAGA 






WXTRN 


BSC ENTRY 






WXTRN 


SOIX 






WXTRN 


SBPI 






WXTRN 


SDIS 






WXTRN 


SDOX 






WXTRN 


SAIX 






WXTRN 


SOOS 






WXTRN 


SAIS 






WXTRN 


SBSCFDD-) 






WXTRN 


SOI 






WXTRN 


SAOX 






WXTRN 


SOOP 






WXTRN 


SDO 






WXTRN 


SAI 






WXTRN 


IQVIRT 






WXTRN 


EXIO 






WXTRN 


STP 






WXTRN 


SAO 






WXTRN 


STPDVAOR 






WXTRN 


SDIA 






WXTRN 


»EXI0DD9 






WXTRN 


SOOA 






WXTRN 


SAIA 






WXTRN 


lOLOAD 






WXTRN 


SPROGl 






WXTRN 


D4963IHI 






WXTRN 


CNTLBUSY 






WXTRN 


VRY^966 






WXTRN 


04966B 






WXTRN 


TAPEIO 






WXTRN 


VRY4969 






WXTRN 


CNTLEND 






WXTRN 


RD2741 






WXTRN 


R04013 






WXTRN 


WR2741 






WXTRN 


WR^013 






WXTRN 


EXIOCLEN 






WXTRN 


DEQBSC 






WXTRN 


ACLOSE 






WXTRN 


lOUNLOAO 






WXTRN 


SSVCSIA 






WXTRN 


TPINIT 






WXTRN 


INIT40I3 






WXTRN 


BSCINIT 






WXTRN 


TAPEINIT 






WXTRN 


SBIOINIT 






WXTRN 


SSVCLSB 






WXTRN 


EXIOINIT 






WXTRN 


RW4963I0 






WXTRN 


D4963ATN 






WXTRN 


DOBFIX 






WXTRN 


CCBFIX 






OUTPUT NAME 


= SUPVLINK 






ESD TYPE LABEL 


ADDR 


LENGTH 


CSECT 


EDXSYS 


0000 


052E 


ENTRY SSTART 


0230 




ENTRY RETURN 


0238 




ENTRY SDMDDB 


0260 




ENTRY SIPLVOL 


0262 




ENTRY tTIMRTBL 


0264 




ENTRY STESTADR 


0268 




ENTRY STPDDB 


026A 




ENTRY SBSCAODR 


0290 




ENTRY EOXFLAGS 


0298 




ENTRY SVCFLAGS 


029A 




ENTRY SSBPITAB 


029C 




ENTRY LCBA 


029E 




ENTRY SDMVDL 


02A0 




ENTRY SVCBFIN 


02B0 




ENTRY SVCBFOUT 


02B2 





Figure A-4. Link control file (3 of 8) 
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ENTRY 


SVCRTRN 


02B<r 


ENTRY 


SVCLl 


02B6 


ENTRY 


SVCLT 


02B6 


ENTRY 


SVCL2 


02BE 


ENTRY 


SVCL3 


02C6 


ENTRY 


SVCLSB 


02CE 


ENTRY 


SVCIAR 


02CE 


ENTRY 


SVCAKR 


02D0 


ENTRY 


SVCLSR 


0202 


ENTRY 


SVCRO 


0204 


ENTRY 


SVCRl 


0206 


ENTRY 


SVCR2 


0208 


ENTRY 


SVCR3 


02DA 


ENTRY 


SVCR4 


02DC 


ENTRY 


SVCR5 


0206 


ENTRY 


SVCR6 


02EO 


ENTRY 


SVCR7 


02E2 


ENTRY 


SVCIIAR 


02E4 


ENTRY 


SVCILSB 


02E4 


ENTRY 


SVCIAKR 


02E6 


ENTRY 


SVCILSR 


02E8 


ENTRY 


SVCIRO 


02EA 


ENTRY 


SVCIRl 


02EC 


ENTRY 


SVCIR2 


02EE 


ENTRY 


SVCIR3 


02F0 


ENTRY 


SVCIR4 


02F2 


ENTRY 


SVCIR5 


02F4 


ENTRY 


SVCIR6 


02F6 


ENTRY 


SVCIR7 


02F8 


ENTRY 


UNCHAKRl 


02FA 


ENTRY 


UNCHSAV6 


02FC 


ENTRY 


SVCPARMS 


0300 


ENTRY 


CMDTA3LE 


0306 


CSECT 


tEDXOEF 


052E 


ENTRY 


SVCBF 


0530 


ENTRY 


SSVCIbUF 


0530 


ENTRY 


SVCBFEND 


0580 


ENTRY 


SSTORAGE 


0580 


ENTRY 


SBLOCKCT 


0580 


ENTRY 


SMEMSIZE 


0590 


ENTRY 


DATEFMT 


0592 


ENTRY 


SPARTSZE 


0594 


ENTRY 


STOREMAP 


OSA-t 


ENTRY 


MAPEND 


0584 


ENTRY 


tMAPAREA 


05C4 


ENTRY 


SNUHPART 


0686 


ENTRY 


SINITPRT 


0688 


ENTRY 


UN IT MOD 


06BA 


ENTRY 


TIMERDDB 


068C 


ENTRY 


TIMERO 


068C 


ENTRY 


TIMER 1 


06B6 


ENTRY 


OMVOL 


0606 


ENTRY 


OMODB 


0704 


ENTRY 


OHIPL 


08A2 


ENTRY 


FIRSTCCB 


09AA 


ENTRY 


TERMOEFS 


09AA 


ENTRY 


$SYSL3G 


OAOC 


ENTRY 


OISPLAYl 


0BE6 


ENTRY 


tSYSLOGA 


OOAA 


ENTRY 


SSYSLOGB 


OFBC 


ENTRY 


iSYSPRTR 


1272 


ENTRY 


MATRIX 


148A 


ENTRY 


iSYSCGH 


1638 


ENTRY 


tEDXPTCH 


1658 


CSECT 


EDXSVCX 


1758 


ENTRY 


SVC 


1758 


ENTRY 


SVGA 


178A 


ENTRY 


SETBUSY 


1704 


ENTRY 


SVC I 


170C 


ENTRY 


WAIT 


1328 


ENTRY 


ENO 


1936 


ENTRY 


OEQ 


1883 


ENTRY 


POST 


1898 


ENTRY 


ATTACHX 


19DE 


ENTRY 


ATTACH 


19E2 


ENTRY 


DETACH 


1A44 


ENTRY 


SUPEXIT 


1A76 


ENTRY 


SUPEXTRL 


lABC 


ENTRY 


SUPLVLXO 


IAE4 


ENTRY 


SATTACH 


1B96 


ENTRY 


SOETACH 


IBEO 


ENTRY 


SCWAIT 


1C02 


ENTRY 


SWAIT 


1C16 


ENTRY 


SPCST 


IC2E 


ENTRY 


SRESETEV 


1C4E 


ENTRY 


SENO 


1C5A 


ENTRY 


SDEO 


ICAO 


ENTRY 


STPTASKl 


ICCO 


ENTRY 


STPTASK2 


1CC4 



122A 



Figure A-4. Link control file (4 of 8) 
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ENTRY 


UNCHAIN 


1CE3 


ENTRY 


tCP 


lO'tO 


ENTRY 


LPGHXPl 


1003 


ENTRY 


LPGMXP2 


lECA 


CSECT 


SDBUGNUC 


2008 


ENTRY 


JTESTCOM 


2008 


ENTRY 


STESTIN 


201E 


ENTRY 


STE STOUT 


2086 


ENTRY 


tTRCSIA 


210A 


ENTRY 


STRCLSB 


217A 


CSECT 


EDXALU 


2192 


ENTRY 


«IFB 


2192 


ENTRY 


«IFDW 


2196 


ENTRY 


a IFW 


219A 


ENTRY 


«IFTEST 


219C 


ENTRY 


iCOMPE 


21CA 


ENTRY 


SCOMPNE 


210E 


ENTRY 


SFINDE 


21F0 


ENTRY 


SFINONE 


2216 


ENTRY 


CGOTO 


2234 


ENTRY 


BRANCH 


2250 


ENTRY 


$EXEC 


2266 


ENTRY 


i-'NOP 


226A 


ENTRY 


CMOSETUP 


226C 


ENTRY 


CMOSTEST 


2272 


ENTRY 


S 00 LOOP 


22CA 


ENTRY 


SCONTINU 


22DA 


ENTRY 


SAV222CR 


22E8 


ENTRY 


SAV^2^CR 


22F0 


ENTRY 


SAV^-V^CR 


2304 


ENTRY 


SAV224CR 


230E 


ENTRY 


SAX222 


232E 


ENTRY 


SA222C 


2334 


ENTRY 


SA222 


2338 


ENTRY 


SSX222 


234A 


ENTRY 


SS222C 


234E 


ENTRY 


SS222 


2352 


ENTRY 


SM222 


2 364 


ENTRY 


SM222C 


2 368 


ENTRY 


SD222 


237C 


ENTRY 


S0222C 


2330 


ENTRY 


GETPAR3 


23C6 


ENTRY 


GETCNT 


230E 


ENTRY 


SA42^ 


23EC 


ENTRY 


SA'»24C 


23F6 


ENTRY 


SSA24 


241A 


ENTRY 


SS42^C 


241E 


ENTRY 


SM42A 


2442 


ENTRY 


SM424C 


2446 


ENTRY 


S0424 


2460 


ENTRY 


SD424C 


2464 


ENTRY 


SX444 


248E 


ENTRY 


SX4<»4C 


2494 


ENTRY 


SX22'tR 


24B2 


ENTRY 


SX224CR 


24BA 


ENTRY 


SD422R 


24F2 


ENTRY 


SD422CR 


24F8 


ENTRY 


«0V1 


2654 


ENTRY 


MOVlC 


265C 


ENTRY 


ANDl 


267A 


ENTRY 


ANDIXX 


2684 


ENTRY 


lORl 


2690 


ENTRY 


lORlXX 


2694 


ENTRY 


EORl 


269C 


ENTRY 


EORIXX 


26A4 


ENTRY 


SHRl 


26AC 


ENTRY 


SHRIXX 


26C0 


ENTRY 


SHLl 


2602 


ENTRY 


SHLIXX 


26E2 


ENTRY 


M0V2 


26FC 


ENTRY 


M0V2C 


2704 


ENTRY 


AN02 


2726 


ENTRY 


AND2XX 


2730 


ENTRY 


I0R2 


273C 


ENTRY 


I0R2XX 


2 740 


ENTRY 


E0R2 


2748 


ENTRY 


E0R2XX 


2750 


ENTRY 


SHR2 


2758 


ENTRY 


SHR2XX 


2768 


ENTRY 


SHL2 


2776 


ENTRY 


SHL2XX 


2786 


ENTRY 


M0V4 


27A0 


ENTRY 


M0V4C 


27B8 


ENTRY 


AND4 


27E2 


ENTRY 


AND4XX 


27EE 


ENTRY 


I0R4 


2804 


ENTRY 


I0R4XX 


2808 


ENTRY 


E0R4 


2810 



085E 



Figure A-4. Link control file (5 of 8) 
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ENTRY 


E0R4XX 


2318 


ENTRY 


SHR't 


2820 


ENTRY 


SHR4XX 


2830 


ENTRY 


SHL4 


283C 


ENTRY 


SHL4XX 


284C 


ENTRY 


MOVEXP 


23DE 


ENTRY 


SCALL 


2942 


ENTRY 


SRETURN 


2966 


ENTRY 


BFRCK 


298A 


ENTRY 


USER 


29BC 


ENTRY 


EOXLOOP 


29E0 


CSECT 


EDXSTART 


29F0 


ENTRY 


INITTASK 


29F0 


ENTRY 


PCHKSIA 


2C24 


ENTRY 


PCHKLS8 


2EIA 


ENTRY 


SFTKSIA 


2E3E 


ENTRY 


STARTPGM 


2EFa 


CSECT 


OISKIO 


2FB6 


ENTRY 


OISKRW 


2FB6 


ENTRY 


0ISKRW05 


3072 


ENTRY 


TAPE060 


30C4 


ENTRY 


OISKIOOO 


313E 


ENTRY 


DCBRETRN 


3224 


ENTRY 


DISKFLIH 


32EA 


ENTRY 


0FLIH04 


331E 


ENTRY 


DISKERRl 


332A 


ENTRY 


DISKERR2 


332E 


ENTRY 


0ISKERR3 


3332 


ENTRY 


0ISKERR5 


3336 


ENTRY 


0ISKER6B 


333A 


ENTRY 


0ISKERR7 


333E 


ENTRY 


DISKER13 


3366 


ENTRY 


DISKPOST 


3384 


ENTRY 


VARYQN 


3394 


ENTRY 


VARYOFF 


3 39C 


ENTRY 


VARYWQRO 


34F2 


ENTRY 


VARYQCB 


34F4 


ENTRY 


VARYOSCB 


34FE 


CSECT 


D49624 


368E 


ENTRY 


D49624A.T 


368E 


ENTRY 


D4962IH1 


3704 


ENTRY 


DFLIH50 


39B2 


ENTRY 


0FLIH54 


39FA 


ENTRY 


DISKATTN 


3A24 


ENTRY 


OATTNOO 


3A2E 


CSECT 


EOXTIO 


3C40 


ENTRY 


tDPEND 


3E52 


ENTRY 


PRSKSP 


3E80 


ENTRY 


CURCTL 


3F2E 


ENTRY 


CTLXFER 


3FE6 


ENTRY 


PRTEXT 


404E 


ENTRY 


NXTCOMO 


4000 


ENTRY 


RDTEXTL 


40EE 


ENTRY 


RDTEXT 


40F2 


ENTRY 


QUESTION 


41EA 


ENTRY 


PRTNUM2S 


4246 


ENTRY 


PRTNUM2 


424C 


•ENTRY 


PRTNUM'tS 


426C 


ENTRY 


PRTNUM4 


4272 


ENTRY 


GETVAL2 


4348 


ENTRY 


GETVAL4 


4366 


ENTRY 


K3TASK 


4456 


ENTRY 


ENOATTN 


4502 


ENTRY 


TERMOUT 


4718 


ENTRY 


TERMINT 


48F0 


ENTRY 


DECSCAN 


480E 


ENTRY 


FLDCLEAR 


4C1C 


ENTRY 


BDCWORD 


4C38 


ENTRY 


DC3W0RD 


4DCA 


ENTRY 


EBBICVT 


4E6C 


CSECT 


EOXTERMQ 


4F88 


ENTRY 


ENQT 


4F83 


ENTRY 


DEOT 


511C 


ENTRY 


OUTERMIN 


5172 


ENTRY 


QUTERM 


5I7A 


ENTRY 


DCTERM 


51EC 


ENTRY 


OQTERMIN 


5224 


ENTRY 


DGTERMB 


525E 


ENTRY 


OEQTERMS 


52CE 


CSECT 


I0S4979 


532A 


ENTRY 


104979 


532A 


ENTRY 


104978 


532A 


ENTRY 


IA4979 


5 820 


ENTRY 


IA4978 


5B20 


CSECT 


IGS4974 


5C34 


ENTRY 


104974 


5C34 


ENTRY 


104973 


5C34 


ENTRY 


IA4973 


5E06 


ENTRY 


IA4974 


5ED6 



05C6 



0608 



0562 



02E0 



Figure A-4. Link control file (6 of 8) 



SYSGEN Listings A-11 



CSECT 


lOSTERM 


5F1<» 


ENTRY 


lOTERM 


5F14 


CSECT 


lOSTTY 


612E 


ENTRY 


WRTTY 


6I2E 


ENTRY 


RDTTY 


6168 


ENTRY 


lATTY 


61CA 


CSECT 


lOSACCA 


63FC 


ENTRY 


WRACCA 


63FC 


ENTRY 


RDACCA 


654A 


ENTRY 


lAACCA 


6702 


ENTRY 


lADELAY 


6878 


ENTRY 


ACCALS 


6882 


CSECT 


IOS3101 


6992 


ENTRY 


103101 


6992 


CSECT 


ASCIITAB 


71<»A 


ENTRY 


TRASCII 


71'tA 


CSECT 


EBASCII 


734C 


ENTRY 


TRE3ASC 


734C 


CSECT 


lOSPOOL 


754E 


ENTRY 


rOSPNQT 


75^E 


ENTRY 


lOSPOQT 


7676 


ENTRY 


lOSPWR 


774C 


ENTRY 


lOSPCMO 


78DC 


ENTRY 


lOSPCLOS 


7932 


ENTRY 


lOSPENt) 


795A 


ENTRY 


lOSPTBL 


79EE 


CSECT 


EDXTIMER 


7A28 


ENTRY 


TIMEROIA 


7A28 


ENTRY 


TIMERIIA 


7A98 


ENTRY 


SETIMER 


7374 


ENTRY 


WAITIMER 


7C6A 


ENTRY 


INTIMEX 


7C8E 


ENTRY 


INTIME 


7C9C 


ENTRY 


GTIMDATE 


7CF4 


ENTRY 


PRINT! ME 


7D20 


ENTRY 


WHATIME 


7D9E 


ENTRY 


SETCLQCK 


7DCa 


CSECT 


SYSLOG 


7EAC 


ENTRY 


LCB 


7EAC 


ENTRY 


SLOGIA 


7EBC 


ENTRY 


SLOGTSK 


7F2C 


ENTRY 


tSLOGIA 


7FC6 


ENTRY 


tSLOGTSK 


7F02 


ENTRY 


iSLOGPRM 


8000 


CSECT 


CIRCBUFF 


800E 


ENTRY 


CIRSTR 


800E 


ENTRY 


CIRIN 


8010 


ENTRY 


CIRENO 


8012 


ENTRY 


CIRCNT 


8014 


ENTRY 


CIRESIZ 


8016 


ENTRY 


CIRESTR 


8018 


CSECT 


RLOADER 


810A 


ENTRY 


LOADPGM 


810A 


ENTRY 


LPGMXPA 


8150 


ENTRY 


LOAOPGMO 


81 BC 


ENTRY 


LOADEXIT 


8386 


ENTRY 


LPGMXPD 


83FA 


ENTRY 


ENDCOOE 


84AA 


ENTRY 


LOAOOCB 


84AC 


ENTRY 


LOAOORG 


84B6 


ENTRY 


LCMDKEY 


840A 


ENTRY 


LCMDTGT 


84DC 


ENTRY 


LOADFHFL 


84E2 


ENTRY 


GETMAIN 


88F0 


ENTRY 


FREEMAIN 


89DA 


ENTRY 


$ACTIVE 


8A7E 


ENTRY 


GOTOTABL 


8050 


ENTRY 


$CANCEL 


80CC 


ENTRY 


STOP 


8F96 


ENTRY 


STOPTASK 


90DA 


CSECT 


EOXFLOAT 


9388 


ENTRY 


FADOOIO 


9388 


ENTRY 


FAODOOO 


9388 


ENTRY 


FAODIOO 


9388 


ENTRY 


FAOOOOl 


9396 


ENTRY 


FAOOOll 


93A4 


ENTRY 


FADDlOl 


93B2 


ENTRY 


FAOOllO 


93C0 


ENTRY 


FADOlll 


93CE 


ENTRY 


FSUBOOO 


93DC 


ENTRY 


FSUBIOO 


930C 


ENTRY 


FSUBOOl 


93EA 


ENTRY 


FSUBOIO 


93F8 


ENTRY 


FSUBOll 


9406 


ENTRY 


FSUBlOl 


9414 


ENTRY 


FSUBllO 


9422 


ENTRY 


FSUBlll 


9430 


ENTRY 


FLOATERR 


9466 


ENTRY 


FMPYOOO 


9478 



021A 
02CE 



0596 



07B8 
0202 
0202 
04DA 



0484 



0162 



OOFC 



127E 



0264 



Figure A-4. Link control file (7 of 8) 
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ENTRY 


FMPYOOl 


9486 




ENTRY 


FMPYOIO 


9494 




ENTRY 


FMPYOll 


94A2 




ENTRY 


FMPYllO 


94B0 




ENTRY 


FMPYIOO 


94B0 




ENTRY 


FHPYIll 


94BE 




ENTRY 


FMPYlOl 


94BE 




ENTRY 


FOIVOOO 


94CC 




ENTRY 


FDIVOOl 


94DA 




ENTRY 


FOIVOlO 


94E8 




ENTRY 


FOIVOIl 


94F6 




ENTRY 


FOIVILO 


9504 




ENTRY 


FDIVIOO 


9504 




ENTRY 


FDIVlll 


9512 




ENTRY 


FDIVlOl 


9512 




ENTRY 


FLTCONV 


9520 




ENTRY 


MOVFPA 


9574 




ENTRY 


M0VFP8 


958A 




ENTRY 


IFFLOAT 


95B8 




ENTRY 


IFFLOATL 


95D0 




ENTRY 


EDXFLENO 


95E8 




CSECT 


EBFLCVT 


95EC 


065C 


ENTRY 


EBFLOaL 


95EC 




ENTRY 


EBFLSTD 


95EC 




ENTRY 


FLEBDBL 


9903 




ENTRY 


FLEBSTO 


9908 




CSECT 


010 


9C48 


0104 


CSECT 


EDXINIT 


904C 


OIBC 


ENTRY 


START 


904C 




ENTRY 


SEDXINIT 


9076 




ENTRY 


INITEXIT 


900A 




ENTRY 


SSBIOINT 


9E76 




ENTRY 


STERMINT 


9E78 




ENTRY 


SDISKINT 


9E7C 




ENTRY 


STAPEINT 


9E7E 




ENTRY 


S4'»78INT 


9E80 




ENTRY 


S4013INT 


9ER2 




ENTRY 


SLOADINT 


9E84 




ENTRY 


SPGMCINT 


9E86 




ENTRY 


JHOSTINT 


9E8A 




ENTRY 


SBSCAINT 


9E8C 




ENTRY 


SEXIOINT 


9E8E 




ENTRY 


STIMEINT 


9E90 




ENTRY 


INITFEAT 


9F04 




CSECT 


DISKINIT 


9F08 


0098 


ENTRY 


DSKPREP2 


A136 




ENTRY 


DSKINITl 


A23E 




ENTRY 


D66INIT 


A 344 




ENTRY 


PREPIDCB 


A406 




ENTRY 


DISKBUFR 


A418 




ENTRY 


OSOPEN 


A69A 




ENTRY 


GETVOL 


A74E 




ENTRY 


ENQVOL 


AB60 




ENTRY 


DEQVOL 


ABC6 




ENTRY 


SDSNFNO 


AC02 




ENTRY 


SOSBIOOA 


AC04 




ENTRY 


SOSBVOL 


AC06 




ENTRY 


SOSBLIB 


AC08 




ENTRY 


SDSIOERR 


ACOA 




ENTRY 


SDSNVTOC 


ACOC 




ENTRY 


SSEXIT 


ACOE 




ENTRY 


SOSOCEA 


ACIO 




ENTRY 


DSS 


AC5C 




CSECT 


LOADINIT 


ACAO 


0610 


CSECT 


TERMINIT 


B2B0 


0200 


ENTRY 


NEXTERH 


B412 




ENTRY 


TERMERRX 


B478 




CSECT 


INIT4978 


B580 


06A0 


CSECT 


SACCARAM 


BC20 


01F6 


CSECT 


TIMRINIT 


BE16 


0158 


MODULE TEXT LENGTH= BF6Et RLD 


C0UNT= 3131 


SUPVLINK ADDED TO E0X002 




SLINK COMPLETION CODE= 


-1 




AT ON 








SLINK ENDED AT 






JUMP ENDJ03tGT»A 







Figure A-4. Link control file (8 of 8) 



SYSGEN Listings A-13 



PROliRAM $UPDATEtE0X002 

NOMSG 

PARM SSYSPRTR SUPVLINK»EDX002 $E0XNUCN»E0X002 YES 

EXEC 

$EOXNUCN STORED 

SUPDATE ENDED AT 
LABEL ENOJOB 

Figure A-5. EndofSYSGEN 
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Appendix B. Program Preparation Listings 



EDX ASSEMBLER STATISTICS 

SOURCE INPUT - STATSRC»E0X002 
HORK DATA SET - ASMWORKt E0X002 
OBJECT MODULE - ASM0UTtE0X002 
STATEMENTS PROCESSED - 70 

NO STATEMENTS FLAGGED 



LOC 



♦ 2 



»4 *6 



♦ 8 



SOURCE STATEMENT 



STATSRC tEDXOOa t STig-XX't I -V3.0.0 



0000 
OOOA 
0014 
OOIE 
0028 
0032 
003<f 
0034 
0036 
0336 
0338 
0342 
0348 
0352 
035C 
0366 
0370 
037A 
0382 
0386 
0390 
039A 
03A4 
03AE 
03b8 
03C2 
03CC 
03CE 
0308 
03DE 
03E8 
03F2 
03FC 
0406 
0408 
0412 
041C 
0426 
0428 
042C 
0434 
043 C 
0444 
044A 
0454 
045E 
0468 
046 E 
0472 
0472 
047A 
047E 
0480 
0488 
048E 
0494 
0496 
0498 
04A2 
04A8 
04AE 
0462 



0008 0709 D6C7 09CI 0440 
0000 05E4 0370 0000 0000 
06E6 0000 0000 0000 0100 
06E4 OOOC 0000 0000 0664 
0000 0000 OUOO 0000 0000 
0000 



0000 
0000 
0000 
0600 
E2D4 
4040 
OOFF 
4040 
OOFF 
0002 
0403 
9025 
B02A 
C303 
C5D9 
902A 
C8C9 
40C1 
4070 
D5C4 
3026 
D6C7 
902A 
C8C9 
06C7 
E3C9 
0640 
8026 
40E4 
E309 
00B2 
0018 
A0A2 
C29E 
A0A2 
005C 
8026 
4006 
0968 
0028 
00A3 

C29E 
9025 
1430 
C29E 
819E 
B02A 
1C3J 
2030 
OOAl 
0432 
805C 
OOAO 
805C 



0300 0000 0000 0000 
0000 0000 0000 0000 



E5C9 
t506 
4040 
0000 
4040 
0000 
0403 
5QD7 
0348 
0001 
C1E2 
4007 
0002 
E340 
D5C4 
C505 

OCOfl 
09C1 
000' 
E340 
09C1 
0605 

lAlA 
0740 
E940 

05C2 
05C2 
0000 
05E6 
05CA 
lAlA 
D7C5 
40C3 
05CA 
05CC 



C4C5 D6F1 6bCl 
0340 

4040 4040 8000 
7FFF 0000 0000 
4040 4040 8800 
7FFF 0000 0000 
C5D5 C440 OsB? 
Ce.40 05BA 

OOOF 8026 1414 
E240 0906 F2E3 
0906 C709 CI 04 
0000 8026 2020 
70C1 E3E3 057D 
40C5 D5E3 C509 
C47D E306 40C5 

E3Ca C540 0709 

0440 

0000 8026 201F 

C1D5 E840 0709 

0440 C6E4 05C3 

4002 C5E8 40E3 

40C2 09C9 05C7 
E3C8 C540 C505 
E2C3 09C5 C505 



0001 055C 
033A 0038 
FFFF 0472 
05E6 

7CC9 04C1 C7C5 
0540 C509 0906 
06C4 C540 7E40 
0001 



0000 0348 0038 

03 5C 

0000 0038 0000 
0000 0038 

0004 OOOB 



05E6 0004 DSOE 04AB 

04HC 04C6 

05C8 0006 

04CC 

05Cfl 0003 



XMPLST4T 



IHAGEaUF 

DSETNAME 

lUCBl 

IUCB2 

START 



CHECK 
GETIMAGE 



WAITONE 



£Z 



PROGRAM 



EXTRN t IMOPEN » t IMDEFN , $ I MPROT t tl MOATA 
BUFFER 763fBYTES 



TEXT 'VIOEOltASMVOL' 

lOCB NHIST=0 

lOCB SCREEN=STATIC 

ATTNLIST (END,OUT»$PF»STATIC) 

ENOT lOCBl 

PRINTEXT 'CLASS ROSTER PROGRAM •, SPACES=l5,LINE=l 



PRINTEXT 'THE PROGRAM* 

PRINTEXT 'HIT ANY PROGRAM FUNCTION KEY T0«fSKIP=2 



PRINTEXT 



OEQT 

WAIT 

IF 

CALL 

IF 

MOVE 

PRINTEXT 



BRING UP THE ENTRY SCREEN* 



ATTNECBfRESET 

I ATTNECB.EOflJ tGOTOiENOIT 

»IMOPENt(OSETNAME) t< IMAGEBUF) 

IXMPLSTAT*2fNE»-l) 

ERRC0DEfXMPLSTAT*2 

•aiMAGE OPEN ERRORt CODE = 



PRINTNUM ERRCOOE 

GOTO ERRQUERY 
ENOIF 

CALL $IM0EFN»(I0CB1) ,( IMAGEBUF) 

ENOT I0CB2 

TERMCTRL BLANK 

CALL SIMPROTf ( IMAGEBUFItO 

CALL $IMDATA,( IMAGEBUF) 

PRINTEXT LINE=4tSPACES=ll 

TERMCTRL DISPLAY 

V«AIT KEY 

GOTO (RtAD,El,E2tE3fE4) ,xypLSTAT*2 

MOVE LINtNrjR,6 

GOTO DELETE 

MOVE LINENdRtll 



00000020 
00000030 



00000040 

00000050 

00000060 

00000070 

00000130 
00000140 



PRINTEXT *HIT "iTTN** AND ENTER ••ENO**TO END*fSKIP=2 00000150 



00000160 
00000170 



00000180 



00000190 
00000240 
00000250 
00000260 
00000270 
00000280 
00000290 



00000300 
0000Ci310 
0000^320 
00000330 
00000340 
00000350 
00000360 
00000370 
00000380 
00000390 
00000400 
00000410 

0U000420 
00000430 
00000440 



Figure B-1. Assembler statistics and listing (1 of 2) 



Program Preparation Listings B-1 



04B8 

04C2 
04C6 
04CC 
04U6 
0408 
040E 
OAES 
04EA 
OAFC 
04FA 
04FC 
0502 
0503 
050A 
050F 
0518 
0522 
052C 
0536 
0538 
0542 
0544 
0544 
054C 
0550 
0556 
0558 
055C 
0560 
0562 
0562 
0?a8 
05BA 
05C0 
05C2 
05C8 
05CA 
05CC 
0506 
05E0 
05E4 
05EE 
05F8 
0602 
060C 
0616 
0620 
062A 
0634 
063E 
065C 
0666 
0670 
067A 
0684 
068E 
0696 
06A2 
06AC 
06a6 
06C0 
06DE 
06E8 
06F2 
06FA 



OOAO 
805C 
OOAO 
805C 
E02A 
2000 
8032 
E02A 
2000 
8032 
602A 
2000 
B035 
A02A 
1C30 
OOAO 
F02A 
0406 
C5E2 
F02A 
2000 
F02A 
2000 
e02A 
1C30 
OOAO 
F030 
0032 
OOAO 
0022 
5050 
6060 
0019 
0010 
0019 
0010 
FFFF 
0000 
0000 
C026 
4006 
0434 
0000 
0000 
0000 
0002 
0000 
0612 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
OOOA 
0000 
5BCI 
0000 
0000 
0000 
0000 
0000 
0000 
0000 



04CC 

05CB 0010 
04CC 

05C8 0015 
05C3 0000 F030 

05C8 0001 
05Ce 0000 F030 

05C8 0001 
05C8 0000 F030 

05C8 0002 
05C8 0003 

0496 

0002 0037 C026 
09C5 40C5 05E3 
406F 4040 802E 
0002 0037 F030 



0004 
0004 
0004 



lOOF 
09C9 
0550 
0004 



E4 
DELETE 



0006 0000 F030 0000 
0006 0005 



0496 
0001 2000 



0382 
FFFF 



6060 6060 6060 6060 
05C2 0001 



05C2 FFFF 
0000 0000 



OEOE 
D7C5 
055C 
0000 
0000 
0000 
0096 
0000 
E704 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0690 
E3E3 
0000 
FFFF 
0000 
0000 
C664 
0000 
0000 



7C09 
0540 

0000 
0382 
0000 
0000 
0610 
D7D3 
0000 
FFFF 
0000 
0000 
05E4 
0234 
0664 
0000 
0000 
0000 
C1E2 
0000 
0000 
05E4 
0000 
0080 
0000 
0000 



C5E3 
6F40 

0234 
05E4 
0000 
0000 
0000 
E2E3 
0000 
0000 
05E4 
0000 
0030 
0000 
0000 
0000 
FFFF 
0000 
0240 
0000 
0000 
0000 
0000 
0000 
0000 
0000 



D9E8 
C02E 

0000 
0000 
0000 
FFFF 
0000 
C1E3 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0001 
0000 
0692 
0000 
0000 
0000 
0000 
0000 
0000 
0000 



READ 



CLEANUP 



ENDIT 

DASHES 
OUT 

STATIC 

ATTNECB 
LINENUR 
ERRCODE 
ERROUERY 



GOTO 


DELETE 


00000450 


MOVE 


LINEN2Rfl6 


00000460 


GOTO 


DELETE 


00000470 


MOVE 


LINENUR, 21 


00000480 


ERASE 


MOOE=LINE,TYPE=OATA,LINc=LINENBR 


00000490 


ADO 


LINENaRfl 


00000500 


EPASS 


MOOt = LINE,TYPE = OATA,LINE = LINENflR 


00000510 


ADO 


LINENUR, 1 


00000520 


ERASE 


MOOE=LINE,TYPE=OATA,LINE=LINENeR 


00000530 


SUBTRACT 


LINENdR,2 


00000540 


PRINTEXT 


LINE=LINENBR,SP4CcS=5 


00000550 


TcRMCTRL 


DISPLAY 


00000560 


GOTO 


WAITONE 


00000570 


QUESTION 


•MORE ENTRIES ? • ,LINE=2,SPACES = 55,N0=CLEAN'JP 


00000580 



ERASE 

ERASE 

PRINTEXT 

TERPQTRL 

GOTO 

ERASE 

OEUT 

GOTO 

PROGSTOP 

DATA 

DATA 

POST 

ENOATTN 

POST 

ENOATTN 

ECB 

DATA 

DATA 

QUESTION 



ENOPROG 



EXTERNAL/UNDEFINED 



END 
SYMBOLS 



SVC 

SUPEXIT 

SETBUSY 

JIMOPEN 

tlHOEFN 

SIMPROT 

$IMDATA 



WXTRN 
WXTRN 
WXTRN 
EXTRN 
EXTRN 
EXTRN 
EXTRN 



COMPLETION CODE 



-1 



Figure B-1 . Assembler statistics and listing (2 of 2) 



M0DE=LINEtLINE=2,SPACES=55fTYPE=0ATA 

H00E=SCREEN,LINE=6 

LINF=6,SPACES=5 

DISPLAY 

WAITONE 

MOOE=SCREENtTYPS=ALL 

START 

X»5050« 
80C'-« 
ATTNECB, 1 

ATTNECa,-l 



F«0« 
F«0« 
•aRETRY OPEN ? • t YES=GETIMAGE»NO=ENDIT 



00000590 
OOOOObOO 

00000610 
00000620 
00000630 
00000640 
00000650 
00000660 
00000670 
00000680 
00000690 
00000700 
00000710 
00000720 
00000730 
00000740 
00000750 
00000760 
00000770 



00000780 



00000790 
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SLINK EXECUTION CONTROL RECORDS 

FROM LINKSTATtEOXOOa 
« THIS LINK CONTROL DATA SET SPECIFIES: 
« 1.1 THE LINKED OUTPUT' OBJECT MODULE MILL 
« BF. STORED IN 'LINKOUT* ON E0X002 

« 2.1 THE AUTOCALL DATA SET IS 'SAUTO* ON 

* ASMLIB (SYSTEM SUPPLIED! 

* 3.) 'ASMOUT* ON EDX002 IS THE ONLY INPUT 

* OBJECT MODULE TO BE INCLUDED 
OUTPUT LINKOUT AUTO=$AUTOf ASMLIB 
INCLUDE ASMOUT 

INCLUDE SIMOPENtASMLIB VIA AUTOCALL 
INCLUDE SIHGENtASHLIB VIA AUTOCALL 
INCLUDE SIMDTYPEtASMLIB VIA AUTOCALL 
INCLUDE SSRETURNt ASMLIB VIA AUTOCALL 
INCLUDE SUNPACKfASMLIS VIA AUTOCALL 
END 
«»««« UNRESOLVED EXTERNAL REFERENCES 
WXTRN SVC 



WXTRN SUPEXIT 






WXTRN SETBUSY 






OUTPUT NAME= 


LINKOUT 






ESQ TYPE 


LABEL 


AODR 


LENGTH 


CSECT 




0000 


06FA 


CSECT 




06FA 


09E8 


ENTRY 


(IMOPEN 


06FC 




ENTRY 


SFILE 


0908 




ENTRY 


DISKBUFR 


095C 




ENTRY 


OSOPEN 


0A7A 




ENTRY 


$DSNFNO 


0FE2 




ENTRY 


SOSBIOOA 


OFE't 




ENTRY 


tOSBVOL 


0FE6 




ENTRY 


SOSBLIB 


0FE8 




ENTRY 


SOSIOERR 


OFEA 




ENTRY 


SDSNVTOC 


OFEC 




ENTRY 


SSEXIT 


OFEE 




CSECT 




10E2 


0E2A 


ENTRY 


SIMDEFN 


10E4 




ENTRY 


SIMPROT 


1180 




ENTRY 


SIMOATA 


1908 




ENTRY 


SAODRTBL 


IEA8 




ENTRY 


SATTRTBL 


1EF8 




CSECT 




I FCC 


0074 


ENTRY 


SIMDTYPE 


IFOE 




CSECT 




1F80 


0028 


ENTRY 


RETURN 


1F80 




CSECT 




1FA8 


0040 


ENTRY 


SUNPACK 


IFAA 





MODULE TEXT LENGTH= lFEa» RLD COUNT= 1015 
LINKOUT ADDED TO EDX002 



SLINK COMPLETION C0DE= -1 
AT 06:38:12 ON 00/00/00 



SLINK ENDED AT 06:38:12 

Figure B-2. Link edit listing 



00010 
00020 
00030 
00040 
00050 
00060 
00070 
00080 
00090 
00100 
00110 
00120 
00130 
00140 
00150 
00160 
00170 
00180 
00190 
00200 
00210 
00220 
00230 
00240 
00250 



08 ««<■ 

08 «"»«■ 

08 ««« 

08 ^^i^i 

08 ««« 

08 ««« 

08 <■<<■» 

08 ««« 

08 ««« 

08 «<Kf 

08 »«« 

08 ««<■ 

08 ««« 

08 »»« 

08 *** 

08 ««« 

08 **« 

08 ««« 

08 «4« 

08 ■!■'»<= 

03 ««« 

03 <><■« 

08 «4=« 

03 «** 



OPERAND 
•COUNT* 



TOO MANY POSITIONAL OPERANDS WERE SPECIFIED 

AN INVALID KEYWORD PARAMETER WAS SPECIFIED 

ONE OR MORE UNDEFINED LABELS WERE REFERENCED 

INVALID NO. OF ELEMENTS IN OPERAND - SHOULD BE 1 OR 2 

INVALID INDEX REGISTER SPECIFICATION - NOT til OR iiZ 

RESULT= OPERAND MUST BE SPECIFIED 

INVALID PRECISION FOR REGISTER OPERATION 

OPERAND 1 IS MISSING 

2 IS MISSING 

IS NOT ALLOWED WITH INDEX REGISTERS 
INVALID OR UNDEFINED OPERATION CODE 
TASK NAME NOT SPECIFIED 
TOO MANY DATA SETS SPECIFIED 
TOO MANY OVERLAY PROGRAMS SPECIFIED 
INVALID PARAMETER COUNT 
START= OPERAND MUST BE SPECIFIED 
DS«= OPERAND MUST BE SPECIFIED 
DSNAME= OPERAND MUST BE SPECIFIED- 
OSLEN= OPERAND IS INVALID 
INVALID PRIORITY SPECIFICATION 
INVALID LEVEL SPECIFICATION 
OPERAND FIELD IS TOO LARGE 
INVALID PREC= SPECIFICATION 
UNBALANCED PARENTHESIS IN OPERAND 
SYMBOL IS MULTIPLY DEFINED 



Figure B-3. $EDXL listing (1 of 4) 
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00260 
002 70 
00280 
00290 
00300 
00310 
00320 
00330 
00340 
00350 
00360 
00370 
00380 
00390 
00400 
00410 
00420 
00430 
00440 
00450 
00460 
00470 
00480 
00490 
00500 
00510 
00520 
00530 
00540 
00550 
00560 
00570 
00580 
00590 
00600 
00610 
00620 
00630 
00640 
00650 
00660 
00670 
00630 
00690 
00700 
00710 
00720 
00730 
00740 
00750 
00760 
00770 
00780 
00790 
00800 
00810 
00820 
00830 
00840 
00850 
00860 
00870 
00880 
00 890 
00900 
00910 
00920 
00930 
00940 
00950 
00960 
00970 
00980 
00990 
01000 
OIOIO 
01020 
01030 
01040 
01050 
01060 
01070 
01080 
01090 
01100 
OHIO 
01120 
01130 



08 «** 

08 «** 

08 **« 

08 ««* 

08 *** 

08 «'<^*> 

08 #** 

08 *** 

08 *** 

08 *** 

08 <"** 

08 *** 

08 «** 

03 «** 

OB ^O^i 

08 *«« 

08 «*« 

08 «««■ 

08 <■*« 

08 *«* 

06 *** 

08 *«« 

08 ««4< 

08 <"** 

08 *** 

08 ««« 

oe «** 

08 ««« 
08 **« 
08 *** 
08 *** 
08 *** 
08 «** 
08 *** 
08 *** 
08 *«« 
08 *«* 
08 «** 



08 
08 
OS 
08 






08 «*« 

08 ««* 

08 *** 
03 «** 

09 ««« 
08 *** 
03 *** 
08 *«* 
08 *** 
08 *** 
08 **« 
08 *** 
08 «*« 
08 *«* 
08 *«* 
08 «<■« 

08 *** 

09 *** 
08 **« 
03 *** 

08 4:4:4: 

08 O**: 

08 4'4:« 

08 «=«4: 

08 *«=4: 

08 <:4:* 

08 *** 

08 *** 

08 4:4:41 

08 «=4'4: 

09 4:*4: 

08 *4>« 

03 «'4'4: 

09 4=4:4: 
08 4'*4: 
08 <:4:<! 
08 4:4:» 
08 4<4:4" 
08 *4:4= 
08 **4: 
08 **4: 
08 4:«:« 
08 4:4:4: 
08 **4! 
08 4=4:4! 
08 4:<t<= 



SYMBOL EXCEEDS 8 CHARACTERS IN LENGTH 

INVALID SELF-DEFINING TERM 

I/O BUFFER ADDRESS NOT SPECIFIED 

QUERY MESSAGE MUST BE SPECIFIED 

INVALID DS= SPECIFICATION 

INVALID PGM= SPECIFICATION 

INVALID PARM= SPECIFICATION 

INVALID LENGTH= SPECIFICATION 

TEXT MESSAGE IS NOT A VALID CHARACTER STRING 

INVALID SYNTAX IN OPERAND FIELD 

NULL OR INVALID BRANCH TABLE ENTRY 

EVENT NAME NOT SPECIFIED 

COPY CODE MODULE NOT DEFINED 

A COPY STATEMENT IS NOT ALLOWED WITHIN COPY CODE 

EITHER YES= OR NQ= MUST BE CODED 

INVALID PROMPT= SPECIFICATION 

INVALID MODE SPECIFICATION 

LABEL MUST BE SPECIFIED 

INVALID MODE SPECIFICATION 

MORE THAN ONE LOCAL 'ATTNLIST' HAS BEEN COOED 

MORE THAN ONE GLOBAL "ATTNLIST* HAS BEEN CODED 

ATTNLIST: SCOPE= MUST BE 'LOCAL* OR 'GLOBAL' 

ILLEGAL NUMBER OF OPERANDS - MUST BE EVEN 

ATTNLIST COMMAND STRING MUST BE 1-8 CHARACTERS IN LENGTH 

NO ACTIVE 'IF* OR 'DO' STRUCTURE 

OPERAND IS NOT 'GOTO' OR 'THEN' 

IF/DO NESTING LIMIT EXCEEDED 

INVALID CONJUNCTION SPECIFED (MUST BE 'AND* OR 'OR* I 

INVALID RELATIONAL OPERATOR SPECIFIED 

CONDITION MUST BE • EQ' OR 'NE' FOR 'STRING COMPARE' 

ACTIVE STRUCTURE IS NOT 'IF' 

•DO WHILE' OR 'DO UNTIL' MUST HAVE EVEN NUMBER OF OPERANDS 

ACTIVE STRUCTURE IS NOT 'DO' 

AN 'IF/ELSE/ENDIF' OR 'DO/ENDOO' CLAUSE HAS NOT BEEN TERMINATED 

ERROR 60 (RESERVED FOR 'DO'J 

SPECIFY •WAIT=YES« OR 'WAIT=NO' FOR DISK OPERATIONS 

IF •WAIT=NO't •ERROR=' AND •END=' MAY NOT BE SPECIFIED 

UNBALANCED QUOTES IN OPERAND 

INVALID PROMPT MESSAGE 

•COUNT' MUST BE A POSITIVE SELF-DEFINING TERM 

INVALID DATA TYPE SPECIFIED 

•COUNT' MAY NOT BE MORE THAN 2 WITH REGISTER OPERANDS 

DATA TYPE MUST BE 'WORD' WITH REGISTER OPERANDS 

•RESULT=' MAY NOT BE SPECIFIED WITH 'MOVE' OR 'MOVEA' 

INVALID 'BUSY' SPECIFICATION 

SECOND OPERAND NOT •RESET* OR 'CLEAR' 

NO JTHER OPERANDS ALLOWED WITH 'TIMER* OR 'ENTER* WAIT 

REGISTER SPECIFICATION INVALID 

INVALID RESOURCE SPECIFICATION 

•CODE* MUST BE SELF-DEFINING TERM 

•NLINES^ MUST BE POS.t SELF-DEFINING TERM 

•NLINtS^ REQUIRED WITH •NSPACES^ SPECIFICATION 

•NSPACES^ MUST hi POS.t SELF-DEFINING TERM 

INVALID OPERAND SPECIFIED ON 'TERMCTRL* 

INVALID •TYPE=*, MUST BE 'DATA' OR 'ALL* 

INVALID •MODE=*t MUST BE *FIELD*t *LINE*f OR *SCREEN* 

INVALID FORMAT IN OPERAND 1 

NO CHARACTER STRING SPECIFIED 

OPERAND 3 IS MISSING 

INCOMPATIBLE MARGINS 

INVALID SPECIFICATION FOR •SCREEN^ 

INVALID SPECIFICATION FOR •OVFLINE* 

NO STORAGE ADDRESS SPECIFIED 

NO BRANCH ADDRESS SPECIFIED 

INVALID SENSOR INPUT/OUTPUT TYPE 

INVALID *ERROR=* SPECIFIED 

*8ITS=* INVALID FOR *AI* AND •AO* 

INVALID •SEQ=» FOR *AI* 

INVALID •BITS=*f MUST HAVE THE FORM *BITS=(UfV)* 

INVALID *LS3* SPECIFIED 

INVALID *PULSE* SPECIFICATION 

INVALID *EOB' SPECIFIED 

INVALID *TERMINAL NAME*t MUST BE 1-8 CHARACTERS 

INVALID HEXADECIMAL CONSTANT SPECIFIED 

NEITHER POSITIONAL NOR KEYWORD PARAMETERS WERE SPECIFIED 

A DATA ADDRESS MUST BE SPECIFIED 

INVALID OR UNSPECIFIED LENGTH OPERAND 

OTE TYPE MUST BE SPECIFIED 

INVALID DUPLICATION FACTOR 

INVALID *FORMAT=* SPECIFICATION 

DATA TYPE MUST BE *WORD* OR *BYTE* 

ILLEGAL CONTINUATION - DATA MUST START IN COLUMN 16 

•BITS=' MUST BE SPECIFIED WITH * TYPE=SUBGROUP' 

PCS NOT SPECIFIED 

INVALID 'ADDRESS=*t MUST BE BETWEEN 'OO^ AND ' FF • 

INVALID •TYPE=' SPECIFIED 

INVALID •BIT='» MUST BE BETWEEN '0' AND '15' 

'SPECPI=' MUST BE SPECIFIED FOR •TYPE=GR0UP' AND 'TYPE=BIT' 



Figure B-3. $EDXL listing (2 of 4) 
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OllAO 
01150 
01160 
01170 
01180 
01190 
01200 
01210 
01220 
01230 
01240 
01250 
01260 
01270 
01280 
01290 
01300 
01310 
01320 
01330 
01340 
01350 
01360 
01370 
01380 
01390 
01400 
01410 
01420 
01430 
01440 
01450 
01460 
01470 
014U0 
01490 
01500 
01510 
01520 
01530 
01540 
01550 
01560 
01570 
01530 
01590 
01600 
01610 
01620 
01630 
01640 
01650 
01660 
01670 
01680 
01690 
01700 
01710 
01720 
01730 
01740 
01750 
01760 
01770 
01780 
01790 
01800 
01810 
01820 
01830 
01340 
01850 
01860 
01870 
01830 
01890 
01900 
01910 
01920 
01930 
01940 
01950 
01960 
01970 
01980 
31990 
02000 
02010 
02020 






08 *«« 
08 *** 
08 *** 
08 *** 
08 **« 
08 *** 
08 *«* 
08 *«* 
08 *«* 
08 *«« 
08 *** 
08 *** 
08 *** 
08 **« 
08 *** 
08 *** 
08 *** 
08 «*« 
08 *** 
08 «** 
08 «»« 
08 «** 
08 *«* 
08 *«* 
08 *«* 
08 *«* 
08 *«<= 
08 *** 
08 *** 
08 **« 
08 *** 
08 *** 
08 *** 
08 «** 
08 *«* 
08 *** 
08 *** 
08 *** 
08 *** 
08 *** 
08 «** 






08 
08 
08 *** 
08 **« 
08 *** 
08 *** 
03 *** 
08 ««* 
08 *** 
08 *** 
08 *** 
08 *** 
08 *** 
08 *** 
08 **« 
08 *** 
08 *** 
08 **« 
08 *** 
08 *** 
03 *** 
Oo *«* 
08 *** 
08 *** 
*** 
*** 



08 
08 
06 *** 
08 *** 
08 ««* 
08 *** 
08 *** 
08 *** 
08 *** 
08 ««* 
08 *** 
08 *«* 
08 *** 
08 *** 
08 *** 
08 *** 
08 *** 
08 *«=* 
03 *** 



INVALID 'POINTS' » MUST BE '0-15' FOR AI OR 'O-l' FOR AO 

•ADC ADDRESS SPECIFIED INSTEAD OF 'MULTIPLEXER* ADDRESS 

INVALID 'RANGES' » MUST BE 5Vt 500MV»200MVf lOOMVt 50MVt20MV»0R» lOMV 

INVALID 'ZCOR='t MUST 3E 'YES' OR 'NO' 

INVALID OR MISSING COUNT= SPECIFICATION 

INVALID OR MISSING SIZE= SPECIFICATION 

INVALID 'LOGMSG='f MUST BE 'YES' OR 'NO' 

INVALID '0S=' ON LOAD 

INVALID '05=' ON OVERLAY LOADt MUST HAVE THE FORM 'OSX' 

NO OPEN 'TASK' STATEMENT FOR THIS 'ENOTASK* 

TYPE COUNT MUST BE BETWEEN AND 255 

INVALID GPIB OPERATION 

INDEX REGISTER IS AN INVALID OPERAND 

INVALID FIRST CHARACTER IN PREC= 

INVALID SECOND CHARACTER IN PREC= 

INVALID THIRD CHARACTER IN PREC= 

MAXIMUM OF 3 PREC= SPECIFICATIONS 

INVALID COUNT= PARAMETER 

INVALID PRECISION FOR IMMEDIATE OPERAND 2 

INVALID DATA TYPE COMBINATION 

TOO FEW PREC= SPECIFICATIONS 

INVALID FORMATS SPECIFICATION 

MAXIMUM OF 8 HEXADECIMAL DIGITS (4 BYTES) PER OPERAND 

DATA TYPE SPECIFICATION IS NOT RECOGNIZED 

FLOATING POINT CONVERSION ERROR OR EBFLCVT NOT IN SUPERVISOR 

IT'JVALID KEYWORD COMGINATION 

STORAGE SIZE MUST BE SPECIFIED ( 16K - 256K) 

MAX. NUMBER OF PROGRAMS NOT BETWEEN 1 AND 100 

INVALID TP= SPECIFICATION ■ 

MAXPROG= AND PARTS= DO NOT MATCH 

PARTITION SIZE EXCEEDS 32 BLOCKS 

INVALIO DISK= OPERAND 

OUT OF SEQUENCEt END=YES PREVIOUSLY SPECIFIED 

TYPE=DSECT IS NOT SUPPORTED 

INVALID OR MISSING DEVICE TYPE SPECIFIED 

A DEVICE ADDRESS MUST BE SPECIFIED 

DEVICE ADDRESS MUST BE FROM X'OO' TO X'FF' 

VOLUME LABEL MUST BE SPECIFIED 

VOLUME LABEL IS MORE THAN 6 CHARACTERS 

INVALID LIBRARY ORIGIN SPECIFICATION 

INVALID OR MISSING VOLUME ORIGLN SPECIFICATION 

INVALID OR MISSING VOLUME SIZE SPECIFICATION 

INVALID OR MISSING FIXED HEAD VOLUME SPECIFICATION 

SECONDARY VOLUMES NOT ALLOWED FOR 4964 

RECORDS PER VOLUME EXCEEDS 32760 

COUNT TOO HIGH IN 'PARMs' OPERAND 

ONLY I HOSTCOMM STATEMENT IS ALLOWED 

INCONSISTENT TOP MARGIN 

INCONSISTENT BOTTOM MARGIN 

INVALID LEVEL SPECIFICATION 

TOO MANY PI= ENTRIES 

INVALID SPECIFICATION FOR ECHO 

STATIC SCREENS ARE NOT SUPPORTED FOR THIS TERMINAL TYPE 

THE SECOND PI ENTRY IS INVALID 

THE TWO PI ENTRIES ARE EQUAL 

THE FIRST PI ENTRY IS INVALIO 

THIS ADDRESS HAS BEEN PREVIOUSLY DEFINED 

INVALID AITYPE= 

INVALID 4982 FEATURE ADDRESS 

INVALID 4982 BASE ADDRESS 

REQUIRED PARAMETER IS MISSING 

SCAN= PARAMETER IS INCORRECT 

ACTIONS PARAMETER IS INCORRECT 

INVALID PARAMETER IN DATA LIST 

FORMAT SPECIFICATION IS INVALIO 

FORMAT - CONVERT SPECIFICATION IS INVALID 

FORMAT - PARENS SPECIFICATION IS INVALID 

FORMAT - DELIMITER SPECIFICATION IS INVALID 

FORMAT - X-TYPE SPECIFICATION IS INVALID 

FORMAT - F-TYPE SPECIFICATION IS INVALID 

FORMAT - I-TYPE SPECIFICATION IS INVALIO 

FORMAT - A-TYPE SPECIFICATION IS INVALID 

FORMAT - NUMERIC SPECIFICATION IS INVALID 

FORMAi - H-TYPE SPECIFICATION IS INVALIO 

FORMAT - /-TYPE SPECIFICATION IS INVALIO 

FORMAT - LIST SPECIFICATION IS INVALID 

FORMAT - EXCEEDS MAXIMUM NUMBER OF SPECIFICATIONS (40) 

FORMAT - MAXIMUM CHARACTER STRING IS 254 

INVALID BSCREAO/BSCWRITE TYPE SPECIFICATION 

INVALID TIMEOUT OPERAND 

INVALID ADDRESS OPERAND 

INVALID RETRIES OPERAND 

INVALID MC OPERAND 

INVALID TYPE OPERAND 

INVALID BSCIOCB ADDRESS SPECIFICATION 

THE TOTAL NUMBER OF OPERAND DELIMITERS EXCEEDS MAXIMUM <50) 

INSUFFICIENT STORAGE AVAILABLE FOR TERMINAL PROCESSING 

LOADER ERROR WHILE PROCESSING TERMINAL STATEMENT 

COUNT NOT BETWEEN AND 32767 



Figure B-3. $EDXL listing (3 of 4) 
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02030 
02C40 
02050 
02060 
02070 
02030 
02090 
02100 
02110 
02120 
02130 
02140 
02150 
04^160 
02170 
02180 
02190 
02200 
02210 
02220 
02230 
02240 
02250 
02260 
02270 
02280 
02290 
02300 
02310 
02320 
02330 
02340 
02350 
02360 
02370 
02380 
02390 
02400 
02410 
02420 
02430 
02440 
02450 
02460 
02470 
02480 
02490 
02500 
02510 
02520 
025 30 
02540 
02550 
02560 
02570 
02580 
02590 
02600 
02610 
02620 
02630 
02640 
02650 
02660 
02670 
02680 
02690 
02700 
02710 
02720 
02730 
02740 
02750 
02760 
02770 
02780 
02 790 
02800 
02810 
02820 
02830 
02840 
02850 
02860 
02870 
02380 
02890 
02900 
02910 



08 *«* F=ORMAT SPECIFICATION NOT ALLOWED WITHIN GET/PUTEDIT 

08 *** INVALID BIT RATE/RANGE SPECIFICATION 

03 *** MUST HAVE LINEDEL OR CR OR ATTN OR COD SPECIFIED 

08 <=** CRDELAY SPECIFIED INCORRECTLY 

08 *** NAME SUBLIST .GT. PARM SUBLIST 

08 *** PART NOT ALLOWED WITH PARAMETERSt EVENT= OR OVLY PROGRAMS 

08 *** PART NOT ALLOWED WITH START= OR LOADPT= 

08 *** PART NOT ALLOWED WITH DSX SPECIFICATIONS 

08 «** INVALID IMMEDIATE OPERAND IN STRING COMPARE 

08 **« INVALID COPYCODE LIBRARY NAME 

OP *«* DISK I/O ERROR DURING OPEN OF COPYCODE DATA SET 

08 «<=* DATA SET NAME $$ NOT PERMITTED FOR COPYCODE 

03 *«« SPECIFIED COPYCODE MODULE IS NOT A DATA SET 

08 *** •COMMAND=' MUST BE SPECIFIED 

08 *** •AODRESS=' MUST BE SPECIFIED 

08 **« INVALID •COMMAND=» 

08 ««« 'LEVEL* MUST BE EITHER Ot It 2t OR 3 

08 ««* 'IBIT* MUST BE EITHER OR 1 

08 **« INVALID HEXADECIMAL ENTRY 

08 *** 'DCS' ADDRESS MUST BE SPECIFIED 

08 ««* •M0D4« MUST BE SPECIFIED 

03 *«* •0EVM0D=« MUST BE SPECIFIED 

08 *** •IOTYPE=' MUST BE 'INPUT' OR 'OUTPUT' 

OB ««* •DATADDR=' MUST BE SPECIFIED 

08 «** •CHAINAO=' MUST BE SPECIFIED 

06 *«« INVALID 'END=' MUST BE 'YES' OR 'NO' 

08 *** 'MAX0CB=' OUT OF LIMITS 

08 «*« 'RSd=' MUST BE EVEN 

08 «** 'RSB=' OUT OF LIMITS 

08 «»* 'PCI=' MUST BE 'YES' OR 'NO' 

08 «** 'XD=' MUST 3E 'YES' OR 'NO' 

08 ««* 'SE=' MUST BE 'YES* OR 'NO' 

08 ««« 'OEVADOR ' POSITIONAL PARAMETER MISSING 

08 ««» 'ECBAODR • POSITIONAL PARAMETER MISSING 

08 *** 'lOCBADDR • POSITIONAL PARAMETER MISSING 
**« INVALID NUMERIC OPERAND 
««* TO KEY SPECIFIED WITH HI OR «2 
«<■* FROM KEY SPECIFIED WITH iJl OR «2 

«=«* INVALID PRECISION SPECIFIED WITH FROM KEY OR TO KEY 
*«« FROM KEY SPECIFIED WITH IMMEDIATE OPERAND 
*** iil OR «2 USED IN FROM KEY OR TO KEY 
*** lA BUFFER LENGTH NOT BETWEEN 10 AND 100 
«*« INVALID 'ADAPTER=' OPERAND CODED 

*«« INVALID VCLJME LABEL ON «C0PYC0D RECORD IN »FDXL 
*** OPERAND FIELD LENGTH EXCEEDS 254 CHARACTERS 
*«* ID= MUST BE SPECIFIEOt AND A UNIQUE 1-6 CHARACTER LABEL 
*** LABEL= MUST BE EITHER SL» NLt OR BLP (DEFAULT=SL) 
**« DENSITY= MUST BE EITHER 800t 1600» OR DUAL CDEFAULT=1600) 
*«* INVALID 'INITPART' OR ' INITMOD' PARM ON 'SYSTEM' 



08 
08 
08 
08 
08 
08 
08 
08 
08 
08 
08 
08 
OS 
08 
08 



NVALID TCB LABEL 
$ASM0006 ASMLIU 
MOVEA AND 
$ASM0001 ASMLIB 



ON 'TCBGET' OR 



^OVERLAY 

MOVE 

«OVERLAY 

^COMMENT 

♦OVERLAY $A3M0002 ASMLIB 

SUB GOTO RESET 

♦COMMENT 

♦OVERLAY $ASM0003 ASMLIB 

♦COMMENT 

♦OVERLAY $ASM0004 ASMLIB 

RDCURSOR TERMCTRL HASHVAL 

♦OVERLAY $ASM0005 ASMLIB 

DETACH ATTNLIST ENDATTN 

♦OVERLAY $ASM0007 ASMLIB 

BUFFER OS lOCB 

♦OVERLAY SASMOOOB ASMLIB 

♦OVERLAY $ASM0009 ASMLIB 

SUBROUT CALLFORT 

♦OVERLAY SASMOOOA ASMLIB 

♦OVERLAY JASMOOOB ASMLIB 

♦OVERLAY SASMOOOC ASMLIB 

♦OVERLAY $ASMOOOD ASMLIB 

♦OVERLAY JASMOOOE ASMLIB 

CONVTO 

♦OVERLAY SASMOOOG ASMLIB 

CONCAT TP STATUS 

♦OVERLAY SASMOOOH ASMLIB 

BSCLINE 

♦OVERLAY SASMOOOI ASMLIB 

♦OVERLAY SASMDOOQ ASMLIB 

♦OVERLAY SASHEXIO ASMLIB 

♦OVERLAY $ASMOOOS ASMLIB 

♦OVERLAY JASMOOOT ASMLIB 

♦OVERLAY SASMOOOU ASMLIB 

♦OVERLAY SASMOOOF ASMLI3 

♦OVERLAY SASMOOOM ASMLIB 

♦COPYCOD ASMLIB 

♦COPYCOD EDX002 

♦♦STOP^^ 



IF 

lOR 

ENCT 

ADD 
STIMtR 



DO 

EOR 

OEQT 

DIVIDE 
RETURN 



'TC3PUT' 
ELSE 
SHIFTL 
COPY 



E.NDIF 

SHIFTR 

USER 



PROGRAM LOAD 



MULTIPLY MULT 
INTIME GETTIME 



DSCB 



PRINDATE PRINTIME OUESTION TEXT 



ENODO 
SORT 



SUBTRACT 
ADOV 



ERASE 



fcNDPROG 


ENOTASK 


PROGSTOP 


TASK 


ATTACH 


DC 


EQU 


DATA 


ECB 


QCB 


EXTRN 


WXTRN 


ENTRY 


CSECT 




READ 


WRITE 


NOTE 


POINT 


CONTROL 


WAIT 


POST 


cNQ 


DEO 


CALL 


GETEDIT 


PUTEOIT 








SBIO 


lOOEF 








FIND 


FINONOT 








FPCONV 


FADO 


FSUB 


FMULT 


FDIVO 


PRINTNUM 


GETVALUE 


READTEXT 


PRINTEXT 


CONVTB 


PLOTGIN 


GIN 


SCREEN 


XYPLOT 


YTPLOT 


BSCREAD 


BSCWRITE 


aSCOPEN 


BSCCLOSE 


BSCinCB 


FORMAT 










FIRSTQ 


LASTO 


NEXTC 


OEFINEQ 




EXIODEV 


IDCB 


DC3 


EXOPEN 


EXIO 


SYSTEM 


STOREMAP 


DISK 


TIMER 


TAPE 


TERMINAL 










HOSTCOMM 


SENSORIO 


ODUSIO 


GETMAIN 


FREEMAIN 


ASMERROR 


$IDEF 


OTE 


SLE 




WHERES 


TCBGET 


TCBPUT 







Figure B-3. $EDXL listing (4 of 4) 
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00010 
00020 
00030 
000^0 
00050 
00060 
00070 
00080 
00090 
00 1 00 
OOllO 
00120 
00130 
00140 
00150 
00160 
00170 
OOIBO 
00190 
00200 
00210 
00220 
00230 
002<t0 
00250 
00260 
00270 
00230 
00290 
00300 
00310 
00320 
00 330 
00340 
00350 
00 360 
00370 
00 380 
00390 
00400 
00410 
00420 
00430 
00440 
00450 
00460 
00470 



JOB 

LOG 



STATIC 
JSYSPRTR 



THIS ASSEMBLY USES A COPY CODE MODULE NAMED ROLL 
ON E0X003. THE *COPVCODE DEFINITION STATEMENT 
DEFINING E0X003 AS THE COPYCODE VOLUME IS IN A 
USER DEFINED LANGUAGE CONTROL DATA SET NAMED 
•STATEDXL'.'STATEDXL* IS A COPY OF THE SYSTEM 
SUPPLIED LANGUAGE CONTROL DATA SET 'SEOXL't 
WITH THE OCOPYCODE STATEMENT FOR EOX003 ADDED. 



PROGRAM 

REMARK 

OS 

DS 

OS 

PARM 

NOMSG 

EXEC 

JUMP 



SEDXASMtASMLIB 

ASSEMBLY OF 'STATSRC STARTED 

STATSRC 

AS^WORK 

ASMOUT 

LIST 



SSYSPRTR 



STATEDXL 



BADASM,NE»-1 



THIS LINK INCLUDES THE 'SIM* SUBROUTINE SUPPORT BY 
USE OF THE AUTOCALL OPTION. THE AUTOCALL DEFINITION 
STATEMENTS FOR THE "SIM* SUPPORT ARE IN THE SYSTEM 
SUPPLIED AUTOCALL DATA SET 'SAUTO* ON ASMLIB. 



PROGRAM 

REMARK 

REMARK 

PAUSE 

DS 

DS 

PARM 

NOMSG 

EXEC 

JUMP 

PROC 

JUMP 

REMARK 

JUMP 

LABEL 

REMARK 

JUMP 

LABEL 

REMARK 

LABEL 

EOJ 



SLINKtEDX002 

LINK EDIT OF 'ASMOUT' OBJECT MODULE STARTED 

NAME OF LINK CONTROL DATA SET ? 

LINKWRKl 
LINKWRK2 
iSYSPRTR 



BAOLINK»NEt-l 

FORMPROC 

ENDtEOt-1 

FORMAT STEP FAILED 

END 

BAOASM 

ASSEMBLY STEP FAILED 

END 

B AOL INK 

LINK EDIT STEP FAILED 

END 



Figure B-4. $JOBUTIL listing 



LOG 


SSYSPRTR 


PROGRAM 


SEDXASMtASMLIB 


OS 


STATSRC 


DS 


ASMWORK 


DS 


ASMOUT 


PARM 


LIST ISYSPRTR 


NOMSG 




EXEC 





STATEDXL 



EDX ASSEMBLER STATISTICS 



SOURCE INPUT 

rtORK DATA SET 

OBJECT MODULE - ASMOUT 

STATtKENTS PROCESSED - 



STATSRC tE0X002 
ASMWORK ,EDX002 
,E0X002 
77 



NO STATEMENTS FLAGGED 



PAGE 1 



SOURCE STATEMENT 



STATSRC tEDX002 



(5719-XX4»-V3.0.0 



0000 
OOOA 
0014 
OOIE 
0028 
0032 
0034 



0008 0709 D6C7 D9C 1 D44U 
0000 05E4 0370 0000 0000 
06E6 0000 0000 0000 0100 
06E4 0000 0000 0000 0664 
0000 0000 0000 0000 0000 
GOOD 



XMPLSTAT 



PROGRAM START 



EXTRN $IMOP£N,$lMOEFMtHMPROTf$IMDATA 



00000010 



00000020 



Figure B-5. STATPROC execution output (1 of 4) 



Program Preparation Listings B-7 



003^ 


0000 


0300 


0000 


0000 


0000 


IMAGEBUF 


BUFFER 


768tBYTES 


003e 


0000 


0000 


0000 


0000 


0000 








0336 


0000 
















0338 


OEOD 


E5C9 


C4C5 


D6F1 


6BC1 


DSETNAME 


TEXT 


•VIOEOltASMVOL' 


03^2 


E2D^ 


E506 


0340 












03^8 


4040 


4040 


4040 


4040 


8000 


lOCBl 


lOCB 


NHIST=0 


0352 


OOFF 


0000 


7FFF 


0000 


0000 








035C 


4040 


4040 


4040 


4040 


8800 


I0CB2 


IOCS 


SCREEN=STATIC 


0366 


OOFF 


0000 


7FFF 


0000 


0000 








0370 


0002 


0403 


C505 


C440 


05B2 




ATTNLIST 


(ENDfOUTt$PF.ST 


037A 


0403 


5B07 


C640 


05BA 











COPY ROLL 
*START OF "COPYCOOE" MODULE 



0382 


9025 


0348 








0386 


B02A 


0001 


OOOf 


8026 


1414 


03 90 


C3D3 


C1E2 


E240 


0906 


E2E3 


039A 


C5D9 


40D7 


D9D6 


C7D9 


C1D4 


03A4 


902A 


0002 


0000 


8026 


2020 


03AE 


C8C9 


E340 


7DC1 


E3E3 


057D 


0338 


40C1 


D5C4 


40C5 


D5E3 


C5D9 


03C2 


4070 


C505 


C47D 


£306 


40C5 


03CC 


05C4 










03CE 


8026 


OCOB 


E3C8 


C540 


0709 


0308 


D6C7 


D9C1 


0440 






03DE 


902A 


0002 


0000 


8026 


20IF 


03E8 


C8C9 


E340 


C1D5 


E840 


0709 


03F2 


D6C7 


09C1 


0440 


C6E4 


D5C3 


03FC 


E3C9 


D605 


4002 


C5E8 


40E3 


0406 


0640 










0408 


8026 


lAlA 


40C2 


D9C9 


D5C7 


0412 


40E4 


07 40 


E3C8 


C540 


C5D5 


041C 


E309 


E840 


E2C3 


D9C5 


C5D5 


0426 


00B2 











START 



ENOT lOCBl 

PRINTEXT 'CLASS ROSTER PROGRAM • ,SPACES= 15»LINE= I 



PRINTEXT "THE PROGRAM' 

PRINTEXT 'HIT ANY PROGRAM FUNCTION KEY T0',SKIP=2 



PRINTEXT 



• BRING UP THE ENTRY SCREEN* 



DEQT 
* END OF "COPYCOOE" MODULE 



0428 


0018 


05C2 








CHECK 


042C 


A0A2 


05C2 


0001 


055C 






0434 


C29E 


0000 


033A 


0038 




GETIMAGI 


043C 


A0A2 


05E6 


FFFF 


0472 






0444 


005C 


05CA 


05E6 








044A 


8026 


lAlA 


7CC9 


D4C1 


C7C5 




0454 


40D6 


D7C5 


0540 


C509 


D906 




045E 


D96B 


40C3 


06 C4 


C540 


7E40 




0468 


0028 


05CA 


0001 








046E 


OOAO 


05CC 










0472 














0472 


C29E 


0000 


0348 


0038 






047A 


9025 


035C 










047E 


1430 












0480 


C29E 


0000 


0038 


0000 






0488 


819E 


0000 


0038 








0485 


302A 


0004 


OOOB 








0494 


1C30 












0496 


2030 










WAITONE 


0498 


OOAl 


05E6 


0004 


050E 


04A8 




04A2 


0482 


043C 


04C6 








04A8 


805C 


05CB 


0006 






El 


04AE 


OOAO 


04CC 










0432 


805C 


05C8 


OOOB 






E2 


0468 


OOAO 


04CC 










04tiC 


805C 


05C8 


0010 






E3 


04C2 


OOAO 


04CC 










04C6 


805C 


05C8 


0015 






E4 


04CC 


E02A 


05C8 


0000 


F030 


0004 


DELETE 


0406 


2000 












0408 


6032 


05C8 


0001 








04DE 


E02A 


05C8 


0000 


F030 


0004 




04E8 


2000 












04EA 


8032 


05C8 


0001 








04F0 


E02A 


05C8 


0000 


F030 


0004 




04FA 


2000 












04FC 


6035 


05C8 


0002 








0502 


A02A 


05C8 


0005 








0508 


1C30 












050A 


OOAO 


0496 










050E 


F02A 


0002 


0037 


C026 


lOOF 


READ 


0518 


D4D6 


D9C5 


40C5 


05E3 


09C9 




0522 


C5E2 


406F 


4040 


802E 


0550 




052C 


F02A 


0002 


0037 


F030 


0004 




0536 


2000 












0538 


FO?A 


0006 


0000 


F030 


0000 




0542 


2000 












0544 


P02A 


0006 


0005 








054A 


1C30 












054C 


OOAO 


0496 










0550 


F030 


0001 


2000 






CLEANUP 



WAIT 



ATTNECB. RESET 



IF lATTNECBTEQtl) tGOTOtENOIT 

CALL $IMOPENt( DSETNAME It (IMAGEBUF) 
IF (XMPLSTAT+2,NEf-l) 

MOVE ERRC0DE»XMPLSTAT*2 
PRINTEXT 'SIMAGE OPEN ERROR, CODE = ' 



PRINTNUM ERRCOOE 



GOTO 
END IF 
CALL 
ENQT 

TERMCTRL 
CALL 
CALL 

PRINTEXT 
TERMCTRL 
WAIT 
GOTO 

MOVE 
GOTO 
MOVE 
GOTO 
MOVE 
GOTO 
MOVE 
ERASE 

ADD 
ERASE 

ADD 
ERASE 

SUBTRACT 

PRINTEXT 

TERMCTRL 

GOTO 

QUESTION 



ERASE 
ERASE 



ERRQUERY 

$IM0EFN,(ICCB1I »l IMAGEBUF) 

I0CB2 

BLANK 

$IMPROT, I IMAGEBUF) tO 

SIMDATA, (IMAGEBUF) 

LINE=4»SPACES=11 

DISPLAY 

KEY 

(REAO,El»E2,E3,E4)»XMPLSTAT+2 

LINENBRf6 

DELETE 

LINEN:3R,11 

DELETE 

LINENBR,16 

DELETE 

LINt:NaR,21 

MODE=LINE,TYPE=DATA,LINE=LINENBR 

LINENBRtl 
MODE=LINE,TYPE=DATA»LINE=LINENBR 

L IN EN BR, 1 
MODE=LINE,TYPE=OATA,LINE=LINENBR 

LINENBR,2 

LINE=LINENBR, SPACES =5 

DISPLAY 

WAITONE 

•MORE ENTRIES ? • t LINE=2»SPACES=55,N0=CLEANUP 



MODE=LINE,LINE=2,SPACES=55,TYPE=OATA 
M00E=SCREEN,LINE=6 



00000030 

00000040 

00000050 

00000060 

00000070 

00000130 
00000001 
00000002 
00000003 
00000130 
00000140 



PRINTEXT 'HIT "ATTN" AND ENTER "ENO"TO EN0'tSKIP = 2 00000150 



PRINTEXT LINE=6,SPACES=5 

TERMCTRL DISPLAY 

GOTO WAITONE 

ERASE MODE=SCREEN,TYPE=ALL 



00000160 
00000170 



00000180 



00000190 
00000200 
00000210 
00000220 
00000240 
00000250 
00000260 
00000270 
00000280 
00000290 



00000300 
00000310 
00000320 
00000330 
00000340 
00000350 
00000360 
00000370 
00000380 
00000390 
00000400 
00000410 

00000420 
00000430 
00000440 
00000450 
00000460 
00000470 
00000480 
00000490 

00000500 
00000510 

00000520 
00000530 

00000540 
00000550 
00000560 
00000570 
00000580 



00000590 

00000600 

00000610 
00000620 
00000630 
00000640 



Figure B-5. STATPROC execution output (2 of 4) 
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0556 


00B2 












DEOT 




00000650 


0558 


OOAO 


0382 










GOTO 


START 


00000660 


055C 


0022 


FFFF 








ENOIT 


PROGSTOP 




00000670 


0560 


5050 












DATA 


X»5050« 


00000680 


0562 


6060 


6060 


6060 


6060 


6060 


DASHES 


DATA 


80C'-' 


00000690 


05iJ2 


0019 


05C2 


0001 






OUT 


POST 


ATTNECB,! 


00000700 


osas 


0010 












ENOATTN 




00000710 


05BA 


0019 


05C2 


FFFF 






STATIC 


POST 


ATTNECB, -I 


00000720 


05C0 


OOID 












ENOATTN 




00000730 


05C2 


FFFF 


0000 


0000 






ATTNECB 


ECB 




00000740 


05C8 


0000 










LINtNBR 


DATA 


F'0» 


00000750 


05CA 


0000 










ERRCODE 


DATA 


F'O' 


00000760 


05CC 


C026 


OEDE 


7CD9 


C5c3 


D9E8 


ERRQUERY 


OUESTION 


•2RETRY OPEN ? • , YES=GETIMAGE,NO=ENOIT 00000770 


0506 


4006 


D7C5 


D540 


6F40 


C02E 










05 EO 


O'ta-t 


055C 
















05E4 


0000 


0000 


0000 


02 34 


0000 




ENDPROG 




00000780 


05EE 


OODO 


0000 


0382 


0564 


0000 










05H8 


0000 


0000 


0000 


0000 


0000 










0602 


0002 


0096 


0000 


0000 


FFFF 










060C 


0000 


0000 


0610 


0000 


0000 










0616 


0612 


t7D4 


D7P3 


E2E3 


C1E3 










0620 


0000 


0000 


0000 


0000 


0000 










062A 


COOd 


0000 


FFFF 


0000 


0000 










063^ 


0003 


0000 


0000 


05E4 


0000 










063E 


0000 


0000 


0000 


0000 


0000 










065C 


nooo 


0000 


05E4 


OORO 


0000 










0666 


0000 


0000 


0234 


0000 


OODO 










0670 


0000 


0000 


0664 


0000 


0000 










067A 


0000 


0000 


0000 


0000 


0001 










06o4 


OOOA 


0000 


0000 


FFFF 


0000 










06dE 


0000 


0690 


0000 


0000 


0692 










0693 


5BC1 


E3E3 


C1E2 


0240 


0000 










06A2 


0000 


0000 


0000 


0000 


0000 










06AC 


0000 


FFFF 


0000 


0000 


0000 










06B6 


0000 


0000 


05E4 


0000 


0000 










06C0 


0000 


0000 


0000 


0000 


0000 










06DE 


0000 


0664 


0080 


0000 


0000 










06E8 


0000 


0000 


0000 


0000 


0000 










06F2 


0000 


0000 


0000 


0000 












06FA 














END 




00000790 



EXTERNAL/UNDEFINED SYMBOLS 





SVC 


WXTRN 




SUPEXIT 


WXTRN 




SETBUSY 


WXTRN 




SIMOPEN 


EXTRN 




SIMDEFN 


EXTRN 




SIMPROT 


EXTRN 




SIMDATA 


EXTRN 


IN CODE = -1 






BADASM,NE,-1 






$LINK,E0X002 






LINKSTAT 






LINKWRKl 






LINKWRK2 






SSYSPRTR 







JUMP 
PROGRAM 
OS 
DS 
OS 

PARM 
NOMSG 
EXEC 

SLINK EXECUTION CONTROL RECORDS 
FROM LINKSTAT, EDX002 

* THIS LINK CONTROL DATA SET SPECIFIES: 

* l.» THE LINKED OUTPUT OBJECT MODULE WILL 

* BE STORED IN 'LINKOUT* ON cDX002 

* 2.) THE AUTOCALL DATA SET IS • SAUTO' ON 

* ASMLIB tSYSTEM SUPPLIEDI 

* 3.) 'ASMOUT* ON EDX002 IS THE ONLY INPUT 

* OBJECT MODULE TO BE INCLUDED 
OUTPUT LINKOUT AUTO=$AUT0, ASML IB 
INCLUDE ASMOUT 

INCLUDE SIMOPEN, ASMLId VIA AUTOCALL 
INCLUDE SIMGEN, ASMLIB VIA AUTOCALL 
INCLUDE SIMDTYPE, ASMLIB VIA AUTOCALL 
INCLUDE SSRETURN, ASMLIB VIA AUTOCALL 
INCLUDE SUNPACK, ASMLIB VIA AUTOCALL 
END 



Figure B-5. STATPROC execution output (3 of 4) 
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»*««« UNRESOLVED EXTERNAL REFERENCES 

WXTRN SVC 

WXTRN SUPEXIT 

WXTRN SETBUSY 
OUTPUT NAME= LINKOUT 



ESD TYPE 


LABEL 


AOOR 


LENGTH 


CSECT 




0000 


06FA 


CSECT 




06FA 


09E8 


ENTRY 


SIMOPEN 


06FC 




ENTRY 


SFILE 


0908 




ENTRY 


OISKBUFR 


095C 




ENTRY 


DSOPEN 


OAT A 




ENTRY 


SOSNFND 


0FE2 




ENTRY 


SOSBIODA 


OFE^ 




ENTRY 


SDSBVOL 


0FE6 




ENTRY 


tOSBLIB 


0FE8 




ENTRY 


tDSIOERR 


OFEA 




ENTRY 


SOSNVTOC 


OFEC 




ENTRY 


$$EX1T 


OFEE 




CSECT 




10E2 


0E2A 


ENTRY 


SIMOEFN 


l0E<t 




ENTRY 


tIMPROT 


1180 




ENTRY 


JIHOATA 


1908 




ENTRY 


SADDRTBL 


1EA8 




ENTRY 


SATTRTBL 


IEF8 




CSECT 




IFOC 


0074 


ENTRY 


SIMDTYPE 


IFOE 




CSECT 




1F80 


0028 


ENTRY 


RETURN 


1F80 




CSECT 




1FA8 


0040 


ENTRY 


$UNPACK 


IFAA 





MODULE TEXT LeNGTH= 1FE8» RLO COUNT= 1015 
LINKOUT ADDED TO EOX002 



$LINK COMPLETION CODE= 



-1 



SLINK ENDED 

JUMP BA0LINK»NE.-1 

PROGRAM tUPDATE 

PARM tSYSPRTR LINKOUT 

NOMSG 

EXEC 

STATPROG STORED 



STATPROG YES 



SUPDATE ENDED 
JUMP EN0»E0»-1 
LABEL END 

Figure B-5. STATPROG execution output (4 of 4) 
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